Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Replication of frames with "record/track changes" (redlines), Writer freezes|
|Component:||editing||Assignee:||AOO issues mailing list <issues>|
|Status:||CLOSED IRREPRODUCIBLE||QA Contact:|
|Priority:||P3||CC:||binbjguo, elish, issues, orw|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
Description stfhell 2012-12-08 22:45:10 UTC
When using "Record changes", Writer sometimes starts continuous replication of frames. After it has produced several thousand copies of the same frame, it usually freezes at some stage with 100% CPU usage, and you have to kill the process. If you kill it fast enough after it becomes unresponsive, you can continue with the last auto-saved version of the document. If an auto-save happens after replication has started, there remains only the solution of hand-editing the content.xml: You have to find the frame that gets repeated both in the <text:tracked-changes> section and in one of the following <text:p> elements, and delete all instances. Writer seems to endlessly put the frame in question into the <text:deletion> element and copy it into the text paragraph (or vice versa). It is very difficult to track down the bug because you may be editing a different part of the file when Writer starts replication. But I believe that it concerns frames that get deleted while "Record changes" is active. I have managed to avoid this bug with good success by turning "Record changes" off whenever possible and by postponing using frames until recorded changes are accepted. I will add some sample documents that are also available from the equivalent LibreOffice bug report (#fdo50057) https://bugs.freedesktop.org/show_bug.cgi?id=50057 Also see Bug 75680 Comment 5, which seems to address the same problem. I'm not sure if Bug 75680 Comment 3 about alphabetic-index-marks in the deletion redline is related to the same bug. Saw this bug in OpenOffice under Ubuntu 9 and 10, and in OpenOffice (and LibreOffice) under Ubuntu 12.04. Also confirmed in LibreOffice BZ under Windows 7. Now tested with AOO 3.4.1 (under Ubuntu 12.04/AMD64).
Comment 1 stfhell 2012-12-08 22:51:37 UTC
Created attachment 80011 [details] content_replicated_frames.xml: formatted excerpt of defective content.xml Excerpt from a content.xml I edited by hand to get rid of the replicated frames. I deleted most of the parts surrounding the relevant <text:changed-region> and <text:p> elements.
Comment 2 stfhell 2012-12-08 23:03:33 UTC
Attachment: Frame_replication_bug.zip Download from https://bugs.freedesktop.org/attachment.cgi?id=65920 (Apache BZ does not accept attachments larger than 1 MB.) Load the file, and when Writer reaches the "defective frame", it will get unresponsive to the point of freezing. (I cannot attach unmodified documents because they are confidential. But I managed to "anonymize" this file: Replication starts when Writer lays out the page, which takes some time with a file of this size and gave me the time for text substitutions.)
Comment 3 stfhell 2012-12-08 23:09:44 UTC
Created attachment 80012 [details] Test1.zip: smaller sample file Much smaller file with external images. Behaves differently, with slower replication of frames. Same attachment as in https://bugs.freedesktop.org/show_bug.cgi?id=50057 Open the file, and edit it. Frame replication is slow and stops in between. You can use Navigator to see how frames get replicated. Or: Open the file, enable "View changes". Edit the file. Writer freezes much faster.
Comment 4 stfhell 2012-12-08 23:13:24 UTC
(In reply to comment #2) > Attachment: Frame_replication_bug.zip Sorry, the URL to Frame_replication_bug.zip in Comment 2 was wrong. Download it from: https://bugs.freedesktop.org/attachment.cgi?id=67118
Comment 5 Oliver-Rainer Wittmann 2012-12-11 09:10:34 UTC
Comment 6 binguo 2012-12-21 09:31:04 UTC
Verified this bug on Aoo_Trunk_20121214.1915 Rev.1413470, No Freezes, would you please verify this on latest build, keep it in uncomfirmed.
Comment 7 stfhell 2012-12-21 12:25:05 UTC
I tested file "1077_replicate.odt" and could reproduce the bug with AOO350m1(Build:9611) - Rev. 1420743 2012-12-13_04:34:45 - Rev. 1421074 (Linux64 dev snapshot under Ubuntu 12.04/AMD64). The test file is the one in fdo-attachment 67118 [details]. I uploaded it to https://docs.google.com/open?id=0B1LoCI_Pl4cjQi1RZFVDOE4tbm8 because it is over 1 MB. The ZIP also contains the "saved-as" versions. The test steps I did: 1. Load file 1077_replicate.odt. Soon after loading, AOO becomes unresponsive for about 12 mins. (with 100% CPU usage for 1 CPU core). 2. Without doing any edits, save as 1077_replicate_02.odt. Saving takes about 5 mins. Immediately afterwards AOO becomes again unresponsive for about 45 mins. 3. Without doing any edits, save as 1077_replicate_03.odt. Saving takes about 14 mins. AOO again unresponsive afterwards. Since the doc was not edited between the file saves, there should be no changes, of course, apart from document metadata like timestamps. But the 3 files look like this: 1077_replicate.odt: ODT file: 1,913,080 bytes contained content.xml: 5,924,477 bytes 1077_replicate_02.odt: ODT file: 1,983,709 bytes contained content.xml: 10,309,522 bytes 1077_replicate_03.odt: ODT file: 2,114,476 bytes contained content.xml: 19,077,734 bytes
Comment 8 stfhell 2012-12-21 12:49:50 UTC
Tested file "Test1.odt" from Attachment 80012 [details], also with AOO350m1(Build:9611) - Rev. 1420743 2012-12-13_04:34:45 - Rev. 1421074 (Linux64 dev snapshot under Ubuntu 12.04/AMD64). The file stays more manageable as long as the number of replicated frames is not too high. You can open the navigator in between unresponsive phases. Test steps I did: 1. Load file Test1.odt. 2. Turn on "Edit / Changes / Show". 3. Insert about 30 random characters in a new paragraph after deleted paragraph "Changed Paragraph 2". You can see how the frames replicate when you open the navigator. Shortly after loading of the original document, it contains 5 frames and 15 graphics. After inserting some text as in step 3, there are 20 frames and over 56 graphics after about 1 minute. Several frames and graphics get the same name. Replication also starts when you just delete some of the existing text without showing recorded changes before.
Comment 9 stfhell 2013-06-05 15:33:46 UTC
I also verified it on a recent snaphot, AOO400m2(Build:9701) - Rev. 1489073 2013-06-03 18:40:40 (Mon, 03 Jun 2013) - Linux x86_64: - Opened file "077_replicate.odt" and saved it under a new name without any changes. It took several minutes to save the file, saved file was larger: 1077_replicate.odt: 1913080 bytes 1077_replicate_aoo4_01.odt: 1981282 bytes AOO became unresponsive after the save, I couldn't save the file a second time and killed the process. - Opened file "Test1.odt", enabled "Show Changes" and saved the file under new names without any edits in between. Writer became more and more unresponsive, took longer and longer to save the file, and the file became bigger and bigger although I didn't edit it: 41464 bytes, original file: Test1.odt 34948 bytes, Jun 5 16:15: Test1_aoo4_01.odt 35286 bytes, Jun 5 16:16: Test1_aoo4_02.odt 35959 bytes, Jun 5 16:18: Test1_aoo4_03.odt 37419 bytes, Jun 5 16:23: Test1_aoo4_04.odt 39681 bytes, Jun 5 16:47: Test1_aoo4_05.odt After the 5th save, AOO stayed unresponsive for over 40 minutes and I killed the process.
Comment 10 stfhell 2013-06-06 12:01:25 UTC
There is a similar-looking bug report about replication of alphabetical index marks (not frames), also in combination with "record changes" (redline): Bug #29842 (Documents freezing OOo)