Download it now!
Bug 88169 - FILEOPEN Endless loop opening DOC file when LO in Japanese
Summary: FILEOPEN Endless loop opening DOC file when LO in Japanese
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.5.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Stephan Bergmann
URL:
Whiteboard: target:5.0.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: CJK
  Show dependency treegraph
 
Reported: 2015-01-07 18:01 UTC by Urmas
Modified: 2015-12-17 08:43 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Urmas 2015-01-07 18:01:22 UTC
The attachment 74567 [details] causes the LO into the endless loop on opening it, at least since December 12 build.
Comment 1 Yousuf Philips (jay) (retired) 2015-01-07 21:24:41 UTC
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
Comment 2 Urmas 2015-01-07 22:21:36 UTC
Indeed. How silly of me.

It seems that it hangs only when the language support for Japanese is selected in Language settings.
Comment 3 Yousuf Philips (jay) (retired) 2015-01-08 07:53:08 UTC
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.
Comment 4 Urmas 2015-01-08 09:38:43 UTC
i.e. 'Asian language support' checked and the default document Asian language set to Japanese. My platform is Windows.
Comment 5 Buovjaga 2015-01-08 13:26:11 UTC
(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
Comment 6 isana 2015-01-08 13:28:41 UTC
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
Comment 7 isana 2015-01-08 14:12:31 UTC
(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.
Comment 8 Matthew Francis 2015-04-08 07:10:32 UTC
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
Comment 9 Stephan Bergmann 2015-04-08 08:44:40 UTC
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."
Comment 10 Matthew Francis 2015-04-08 09:38:12 UTC
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
Comment 11 Stephan Bergmann 2015-04-08 11:13:33 UTC
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
Comment 12 Commit Notification 2015-04-08 13:34:03 UTC
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.
Comment 13 Robinson Tryon (qubit) 2015-12-17 08:43:24 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]