Bug 77308 - FILESAVE: .odt file with over-long text:style-name won't open in LO 4.1 and earlier branches and AOO
Summary: FILESAVE: .odt file with over-long text:style-name won't open in LO 4.1 and e...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.1.1 release
Hardware: Other All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:4.3.0
Keywords:
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2014-04-11 07:50 UTC by Juang Dse
Modified: 2014-11-03 12:49 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
problem file (30.78 KB, application/vnd.oasis.opendocument.text)
2014-04-11 07:50 UTC, Juang Dse
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Juang Dse 2014-04-11 07:50:38 UTC
Created attachment 97214 [details]
problem file

The attached file foo.odt was written with LO4.2.1.1. When trying to open it with LO3.5.4.2, it hangs.
Comment 1 Julien Nabet 2014-04-11 11:19:37 UTC
LO 3.5.4.2 is quite old, perhaps it's a bug on this version.
Does it hang too with 4.1.5?
Comment 2 Juang Dse 2014-04-11 15:37:20 UTC
yes, also with 4.1.5.
Comment 3 Juang Dse 2014-04-11 15:56:25 UTC
plus it eats memory and takes up all cpu.
Comment 4 Julien Nabet 2014-04-12 12:16:20 UTC
I can reproduce the problem with 4.1.5.3 LO Debian testing package.

Now I don't know if it's a bug from 4.2 version or if it's due to a bug from before 4.2 version.

Anyway, I don't have anymore questions so put it back to UNCONFIRMED
Comment 5 tommy27 2014-04-13 08:03:26 UTC
tested under Win7x64

test file can be opened in 4.2.2.1 while it hangs with 4.1.5.3

status --> NEW

@Juang Dse

as said by Julien the 3.5.4.2 version you used is way too old and obsolete.

the 4.1.5.x branch is almost close to end of life...
the last 4.1.6 release will come in next weeks but I cannot assure that it will fix the bug.

you should consider upgrade to LibO 4.2.3.3 which has been released a few days ago and is a quite stable release.

changed summary notes
Comment 6 Juang Dse 2014-04-13 11:03:32 UTC
I know.

It is not me who is using 3.5 but my coworkers who prefer to use Ubuntu LTS. And I prefer to have interoperability of odt files across LO versions.
Comment 7 Julien Nabet 2014-04-13 11:21:28 UTC
Juang: you coworker may add ppa repository (see https://launchpad.net/~libreoffice/+archive/ppa)
Comment 8 Juang Dse 2014-04-13 14:13:07 UTC
I know, thanks.

But as mentioned, my coworker prefers stabilty and expects it from the LTS when reading odt format.
Comment 9 tommy27 2014-04-13 15:59:24 UTC
(In reply to comment #6)
> ...
> And I prefer to have interoperability of odt files across LO versions.

besides that, that 4.2.x LibO file won't open in AOO 4.0.0 as well.
I raise the importance level.

I agree interoperability of odt files is important, let's remember it freezes event recent LibO 4.1.5 and AOO 4.0.0

@Juang
would you please do another test?
try creating from scratch the same problematic file in 4.1.5.3 and 4.2.3.3, and tell us if other release can open that file.

I think that the bug is not about older release not being able to open a file created by the 4.2.x, but instead the bug is that the new 4.2.x can't save a file which is readable by older ones.

according to this I change version field to 4.2.1.1 and modify summary from FILEOPEN to FILESAVE
Comment 10 Jean-Baptiste Faure 2014-04-13 19:28:46 UTC
Your test file seems to have been build using Zotero citation extension. The question is: is the problem in LibreOffice or in the use of a version of Zotero not compatible with old LO versions?

Best regards. JBF
Comment 11 Juang Dse 2014-04-13 21:52:57 UTC
There was a Zotero section left over in the document, but the problem still remains after removing it and after completely disabling Zotero.

The main problem is probably related to a very strange naming of the bibliography styles that was left over from an older file - with extremely long names that I see in the xml. That means, no, I cannot reproduce the problem file from scratch.
Comment 12 tommy27 2014-04-14 06:48:14 UTC
is it that the only document where you experience such kind of incompatibility with older LibO releases?
Comment 13 Juang Dse 2014-04-14 08:12:04 UTC
So far, yes.
Comment 14 tommy27 2014-04-14 12:08:28 UTC
Ok. so probably is not that bad after all.
anyway I think our devs should take a look at that file to understand what causes the bad compatibility with older older LibO releases.

I put Writer expert on CC-list

@Micheal Stahl
what do you think about this file?
I let yuo decide if keeping the current report in the mab4.2 list or remove it.
Comment 15 Jean-Baptiste Faure 2014-04-29 07:39:22 UTC
The problem is in the index. In LO 4.2, if I remove it (right click on the word Bibliography and select Delete Index/Table) then save and reopen with LO 4.1.5, then the file opens without problem.

Best regards. JBF
Comment 16 Michael Stahl (CIB) 2014-04-29 12:30:21 UTC
4.1 loops inside SwFormTokensHelper::SwFormTokensHelper
because its input is truncated to 2^16 characters,
and it can't find its terminating ">" character that was cut off.

4.2 can read it because the tools Strings with their 16bit limit
are gone, and the input is not truncated.

the input contains several text:style-name attribute values
on text:index-entry-bibliography elements from the content.xml,
and the problem is that each of those is > 22k characters long,
which is probably not intended...

i'll push a fix for the infinite loop to master (just in case
somebody it's possible to set such invalid input via the UNO API),
but it would be really interesting to know where the
ridiculously long "text:style-name" come from.

can somebody reproduce creating such a file from scratch?
what are the steps to do it?
Comment 17 Commit Notification 2014-04-29 12:32:16 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a03c88eded807da34d0490ab4e1830e7573338e9

fdo#77308: SwFormTokensHelper avoid infinite loop on invalid input



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 18 QA Administrators 2014-11-02 16:46:36 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team
Comment 19 Juang Dse 2014-11-02 18:02:57 UTC
I suppose the needed info relates to reproducing the ridiculously long "text:style-name". I cannot, but I suspect it is a left-over from the old Bibliography Database (under Tools) which I used some time ago.
Comment 20 Michael Stahl (CIB) 2014-11-03 12:49:55 UTC
ok, since nobody came up with steps to reproduce the over-long text:style-name bug in versions later than 4.2.1.1 so i'll resolve it as WORKSFORME.