Created attachment 61753 [details] commented snippets from defective content.xml in ODT Problem description: When editing an ODT document with a larger number of tracked changes (redlines), Writer occasionally hangs, formatting the document ad infinitum, with only short intervals when it reacts to user input again. If the file is saved (or autosaved) when this occurs, it is corrupted by having the same draw:frame element being replicated several thousand times in a row. Steps to reproduce: I haven't found a way to trigger this behaviour consciously, unfortunately. But I haven't found a way to avoid it, either... (except for avoiding the record changes function). I cannot disclose the defective documents but I'm attaching commented snippets from the content.xml file of one. Current behavior: When examining the content.xml file in the corrupt ODT, it is pretty obvious where the behaviour comes from: In the text:tracked-changes-section of the file, there is always a text:changed-region/text:deletion element which contains several thousand copies of the same draw:frame element. Likewise, the body section contains a paragraph containing several thousand copies of the same frame. I assume, Writer hangs because it takes so long reformatting the document. In effect, it is impossible to edit the file in Writer, so there is no way to simply remove the paragraph which contains the replicated frames. I usually try to kill LibreOffice (or OpenOffice) before it autosaves the corrupt file, so that I can start again from a recent intact autosaved version. If I fail to do so, I always unzip the content.xml file, search for the several thousand copies of the same lines, delete the sections by hand and zip the edited content.xml back to the ODT. Replicated frames have occurred in documents with a large number of tracked changes and text frames anchored with the paragraph or character. The frame being replicated is usually not the place that I edited at the moment when Writer hangs, so I'm not sure what triggers this behaviour. But it seems to have to do with having inserted frames in a deleted text sequence. Platform (if different from the browser): This last time Ubuntu Linux x86_64, but I have been seeing this bug with several versions of OpenOffice (under 32-bit Ubuntu 9/10) as well.
I get the same problem in 3.5.3.2, build id 350m1(Build:2), which is the latest version available under Ubuntu 12.04. I have a frame with a link to an image. If I scroll to the page containing the image, then the frame replicates. Once there were about 60. After waiting for the page to redraw as new instances of the frame were added, I clicked on the frames, one by one, and deleted them. Today the problem is much, much worse. I waited over an hour, then closed Writer. The contents.xml contains 8,212 copies of the frame! I used emacs to delete an extra 8,210 copies and see what happens. What happened was that as soon as I tried to get to the page where the problem occurs, LO hangs, presumably re-inserting the same frame over and over... BTW, I noticed the following line above where the frame is: <text:h text:style-name="P13" text:outline-level="4"><text:bookmark-start text:name="__RefHeading__10012_38549477811111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111"/><text:span text:style-name="T5">fir_interp2_s</text:span> Semantics<text:bookmark-end text:name="__RefHeading__10012_38549477811111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111"/></text:h>
I used emacs to get rid of the "extra" ones on those __RefHeading tags (a few hundred of them) and got rid of the extra 8,211 frames, and LO is behaving again.
The problem still occurs in 3.5.5.2. I have 16,384 instances of the same frame, all on top of itself.
(In reply to comment #3) > The problem still occurs in 3.5.5.2. > I have 16,384 instances of the same frame, all on top of itself. Could you attach any example documents to allow others to check on different system/build?
I'll have to cleanse it, because it has company confidential info in it. If someone can work on it, that would help immensely, so it would be worth it.
Created attachment 65917 [details] A file demonstrating the replicating picture. The subdirectory with the pictures is forthcoming.
Created attachment 65920 [details] tar file for the images subdirectory. This file should be untarred in the same directory with the attached .odt file. I have the setting "Save files relative to the file system." You might have to adjust this to see the two pictures. To demonstrate the bug: 1. Turn on Edit/Changes/Record Changes. 2. turn off Edit/Changes/Show Changes. 3. put your cursor after the text "Lsklf". 4. Type a few characters, newlines, etc. until the picture starts replicating. Please let me know if this does or does not replicate the problem.
I have tried your attached test document Test1.odt (LO 3.4.4, Ubuntu Linux 64bit). The first picture is being replicated, though I don't get thousand of copies. LO still remains managable, although the constant rerendering/reformatting of the image part of the screen when inserting text makes it difficult. But replications seem to start when I _delete_ text, insertion seems OK.
Great! I'm glad it's reproducible. I hope someone will work on it soon!
I tried the file a second time, now with "show changes" enabled. This time it was worse: Working with LO became impossible because it didn't respond for minuted. Replication of the frame started after the first edit. LO completely stalled after some time. Attached are versions of the file made after some edits with "track changes" and "show changes" enabled (LibreOffice 3.4.4, Ubuntu AMD64 11.10): - inserted a new paragraph between 2 deleted paragraphs (file Test1_edit_1.odt) - inserted a space (file Test1_edit_2.odt) - inserted a "?" (I couldn't save the file anymore, LO didn't respond for over 15 minutes) Steve, I changed the state back to NEEDINFO, I don't think REOPENED would be appropriate when the bug was not even confirmed or assigned, let alone closed. I hope bfoman can reproduce the behaviour as well with your files.
Created attachment 67106 [details] Test1.odt after 2 edits with tracked and visible changes
Created attachment 67118 [details] 1077_replication_bug.odt: Another ODT file displaying replication of frames This is another ODT showing the frame replication. I took one of my old files that I had repaired "by hand", and replaced all characters to be able to post it here as an attachment. It takes a while until replication starts (I suppose after LO has completely loaded all data and is laying out the page in question).
Confirmed with: LO 3.5.6.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Infinite image replication after few edits. LO is unresponsive.
Increased Importance; really a critical issue (data corruption, freezes ...).
The bug shows up when Record changes is on, even if show changes is off.
The effect of this bug is so bad that I cannot edit my document (which is due in two days!). Libreoffice locks up when it gets to the page with the illustration that replicates forever. My only workaround is to edit the xml, removing the replicated frames.
is anybody still experiencing this bug with recent LibO 4.0.4 or 4.1.0 releases?
(In reply to comment #7) > Created attachment 65920 [details] > tar file for the images subdirectory. > > This file should be untarred in the same directory with the attached .odt > file. > I have the setting "Save files relative to the file system." You might have > to adjust this to see the two pictures. > > To demonstrate the bug: > 1. Turn on Edit/Changes/Record Changes. > 2. turn off Edit/Changes/Show Changes. > 3. put your cursor after the text "Lsklf". > 4. Type a few characters, newlines, etc. until the picture starts > replicating. > tested on LibO 4.1.1.2 under Win7 64bit. I think that when you say "replication" you mean blinking and moving of the picture... at least this is what I see on my PC with your test file... se here are my findings: 1- first image "replication" starts immediately after loading the file, then it gets stable after a few seconds. document is still responsive. 2- adding some text and a new line after "Lsklf" --> "replication" starts again then image gets stable after a few seconds. document is still responsive. 3- remove some text --> "replication" starts again but never stops. document is unresponsive. had to kill soffice.bin so the bug is still CONFIRMED. moving from mab3.6 to mab4.0 list since 3.6 is EOL. interestingly if I try opening the test file with LibO 4.2.0 alpha (master build Sept.3) I receive "Read-Error. Error loading file" alert and cannot open that file.
(This is an automated message.) Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Moving to mab4.1 (Bug 60270) because: - 4.0 reached EOL (End Of Life) - bug confirmed in later version
bug still present in 4.2.4.2 moving to mab4.2 list since 4.1.x is EOL
bug still present in 4.3.4.1 moving to mab4.3 list since 4.2.x is EOL
I can confirm this bug using LibreOffice 5.0.1.2 downloaded from libreoffice.org. It is a disaster. My collaborators will no longer use LibreOffice because of it.
I confirm the issue too, still present in LO 5.1.4 (amd64 Windows 7 and GNU/Linux)
Confirmed using 1077_replication_bug.odt from comment #12 Ubuntu 16.04 - LO 5.3dev - so slow it effectively never loads. Document info: -233 pages -approx 1338 redlines (tracked changes) -approximately one fly every 3 pages (based on a brief scan) but 4097 fly frames being saved/restored. The delay comes from the call to DocumentContentOperationsManager::MoveRange(...) Someone with a good understanding of redlines, code optimizing, and overall writer knowledge should work on this bug.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
bug reproduces with OOo 3.3. attachment Test1.odt from comment #6 works with my fix. the attachment 1077_replication_bug.odt from comment #12 takes far too long to load in a dbgutil build, it's at 95 minutes CPU time now and still unusable. i'm hoping it's fixed now.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7db137e87177dbe381186491ca36e3e8fd62ddc2 tdf#50057 sw: fix duplication of at-paragraph anchored flys It will be available in 6.1.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e7b399c94317170e4f6551648f9bbcc5448fd920&h=libreoffice-6-0 tdf#50057 sw: fix duplication of at-paragraph anchored flys It will be available in 6.0.4. 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.