Issue 121452 - Replication of frames with "record/track changes" (redlines), Writer freezes
Summary: Replication of frames with "record/track changes" (redlines), Writer freezes
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: 3.4.1
Hardware: All All
: P3 Normal (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Blocks: 121500
  Show dependency tree
Reported: 2012-12-08 22:45 UTC by stfhell
Modified: 2017-05-20 10:12 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

content_replicated_frames.xml: formatted excerpt of defective content.xml (13.28 KB, application/xml)
2012-12-08 22:51 UTC, stfhell
no flags Details smaller sample file (718.74 KB, application/zip)
2012-12-08 23:09 UTC, stfhell
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
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)

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
Download from
(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] smaller sample file

Much smaller file with external images. Behaves differently, with slower replication of frames.

Same attachment as in

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:

Sorry, the URL to in Comment 2 was wrong.
Download it from:
Comment 5 Oliver-Rainer Wittmann 2012-12-11 09:10:34 UTC
CC myself
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
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:

  ODT file:  1,913,080 bytes
  contained content.xml:   5,924,477 bytes
  ODT file:  1,983,709 bytes
  contained content.xml:  10,309,522 bytes
  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)
Comment 11 Edwin Sharp 2014-03-31 19:05:33 UTC
No problem with attachment 80012 [details]
AOO410m14(Build:9760)  -  Rev. 1582709
2014-03-30_04:11:07 - Rev. 1583103