Created attachment 97214 [details]
The attached file foo.odt was written with LO22.214.171.124. When trying to open it with LO126.96.36.199, it hangs.
LO 188.8.131.52 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 184.108.40.206 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 220.127.116.11 while it hangs with 18.104.22.168
status --> NEW
as said by Julien the 22.214.171.124 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 126.96.36.199 which has been released a few days ago and is a quite stable release.
changed summary notes
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
would you please do another test?
try creating from scratch the same problematic file in 188.8.131.52 and 184.108.40.206, 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 220.127.116.11 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
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":
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:
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:
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!
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 18.104.22.168 so i'll resolve it as WORKSFORME.