The attachment 74567 [details] causes the LO into the endless loop on opening it, at least since December 12 build.
You sure its the same file as its not an rtf but a doc and it loaded fine for me. Version: 4.5.0.0.alpha0+ Build ID: 39ac529d141dcd4de534eddbcc6c07bc49367b90 TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-01-04_00:40:43
Indeed. How silly of me. It seems that it hangs only when the language support for Japanese is selected in Language settings.
Lets let the japanese team have a look at it. @Urmas: Can you clarify what you mean by "language support for Japanese". Do you mean that the UI or locale is set to japanese or default language for documents has asian selected.
i.e. 'Asian language support' checked and the default document Asian language set to Japanese. My platform is Windows.
(In reply to Urmas from comment #4) > i.e. 'Asian language support' checked and the default document Asian > language set to Japanese. My platform is Windows. Reproduced. Win 7 64-bit Version: 4.5.0.0.alpha0+ Build ID: 8c7f6830e767897d3a0e88f75fc8d7ef7fca95dc TinderBox: Win-x86@42, Branch:master, Time: 2015-01-06_00:47:25
It seems to be reproduced in my environment. LO version: 4.4.0.1 OS: MS Windows 8.1 Language of User interface: English (USA) (also installed Japanese) Language of Locale setting: Default - Japanese Default Languages for Documents Western: Default - English (USA) Default Languages for Documents Asian: Default - Japanese (checked) Default Languages for Documents CTL: not cheked
(In reply to isana from comment #6) Also reproduced when "Locale setting:" was "English (USA)". It seems to be reproduced when "Default Languages for Documents" for "Asian:" was "Japanese" or "Default - Japanese". Other asian languages can open the file.
This seems to have broken in two stages; as of (1), loading attachment 74567 [details] with "Tools - Options - Languages - Default Languages for Documents - Asian" set to Japanese crashes immediately. As of (2), it hangs on load instead. Adding Cc: to sbergman@redhat.com, caolanm@redhat.com; I'm not sure which of these is the real problem, or if they are two independent issues. Could you possibly take a look? Thanks (1) commit d77c108922f7ea2c57bc63bbe289bba92f6213a6 Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Thu Jun 19 23:05:42 2014 +0200 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Thu Jun 19 23:05:42 2014 +0200 external/icu: Change flexible array members to be of length 1 instead of 2 (2) commit a2e70c0a329c1746947e0ef76002482bf681a1c9 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Wed Aug 27 15:10:03 2014 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Wed Aug 27 15:10:03 2014 +0100 nInfo is RTL_TEXTTOUNICODE_INFO not RTL_TEXTTOUNICODE_FLAGS Change-Id: If5e0a2bbfbd56a2d647dac608643411eefa1ed73
The crash at (1) was probably addressed with the follow-up fix <http://cgit.freedesktop.org/libreoffice/core/commit/?id=7890a7263f8a6740582bc58328c76613818fe2d5> "update getTableSize (and fRowLen) for dodgy 2-based arithmetic."
Cherry-picked before/at a2e70c0a and rebuilt to confirm; the earlier crash was resolved by Stephan's subsequent commit, so the one at issue here is commit a2e70c0a329c1746947e0ef76002482bf681a1c9 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Wed Aug 27 15:10:03 2014 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Wed Aug 27 15:10:03 2014 +0100 nInfo is RTL_TEXTTOUNICODE_INFO not RTL_TEXTTOUNICODE_FLAGS Change-Id: If5e0a2bbfbd56a2d647dac608643411eefa1ed73
what happens there is that rtl_convertTextToUnicode reports RTL_TEXTTOUNICODE_INFO_SRCBUFFERTOSMALL even though RTL_TEXTTOUNICODE_FLAGS_FLUSH is specified, which looks like a bug in the specific Japanese text encoding's conversion routines; I'll have a look
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d82e94307f1e073a0ccddb506ba5fff3da042b42 tdf#88169: Do not return ..._INFO_SRCBUFFERTOSMALL when ..._FLAGS_FLUSH It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]