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.
LO 3.5.4.2 is quite old, perhaps it's a bug on this version. Does it hang too with 4.1.5?
yes, also with 4.1.5.
plus it eats memory and takes up all cpu.
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
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
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.
Juang: you coworker may add ppa repository (see https://launchpad.net/~libreoffice/+archive/ppa)
I know, thanks. But as mentioned, my coworker prefers stabilty and expects it from the LTS when reading odt format.
(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
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
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.
is it that the only document where you experience such kind of incompatibility with older LibO releases?
So far, yes.
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.
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
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?
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.
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
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.
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.