Bug 50057 - EDITING: Replication of frames when record changes (redlining) is on
Summary: EDITING: Replication of frames when record changes (redlining) is on
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: highest critical
Assignee: Michael Stahl
URL:
Whiteboard: BSA target:6.1.0 target:6.0.4
Keywords:
Depends on:
Blocks: Track-Changes
  Show dependency treegraph
 
Reported: 2012-05-17 10:40 UTC by stfhell
Modified: 2018-04-12 08:56 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
commented snippets from defective content.xml in ODT (13.28 KB, text/xml)
2012-05-17 10:40 UTC, stfhell
Details
A file demonstrating the replicating picture. (40.49 KB, application/vnd.oasis.opendocument.text)
2012-08-21 23:02 UTC, Steve Kelem
Details
tar file for the images subdirectory. (690.00 KB, application/x-tar)
2012-08-21 23:08 UTC, Steve Kelem
Details
Test1.odt after 2 edits with tracked and visible changes (39.90 KB, application/zip)
2012-09-13 12:32 UTC, stfhell
Details
1077_replication_bug.odt: Another ODT file displaying replication of frames (1.80 MB, application/vnd.oasis.opendocument.text)
2012-09-13 19:36 UTC, stfhell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description stfhell 2012-05-17 10:40:13 UTC
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.
Comment 1 Steve Kelem 2012-06-29 15:36:11 UTC
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>
Comment 2 Steve Kelem 2012-06-29 15:56:40 UTC
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.
Comment 3 Steve Kelem 2012-07-02 16:43:41 UTC
The problem still occurs in 3.5.5.2.
I have 16,384 instances of the same frame, all on top of itself.
Comment 4 bfoman (inactive) 2012-07-03 06:12:47 UTC
(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?
Comment 5 Steve Kelem 2012-07-17 17:44:34 UTC
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.
Comment 6 Steve Kelem 2012-08-21 23:02:32 UTC
Created attachment 65917 [details]
A file demonstrating the replicating picture.

The subdirectory with the pictures is forthcoming.
Comment 7 Steve Kelem 2012-08-21 23:08:54 UTC
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.
Comment 8 stfhell 2012-09-12 17:40:59 UTC
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.
Comment 9 Steve Kelem 2012-09-12 18:13:32 UTC
Great! I'm glad it's reproducible. I hope someone will work on it soon!
Comment 10 stfhell 2012-09-13 12:31:07 UTC
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.
Comment 11 stfhell 2012-09-13 12:32:45 UTC
Created attachment 67106 [details]
Test1.odt after 2 edits with tracked and visible changes
Comment 12 stfhell 2012-09-13 19:36:47 UTC
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).
Comment 13 bfoman (inactive) 2012-10-11 13:07:55 UTC
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.
Comment 14 Roman Eisele 2012-11-29 19:38:45 UTC
Increased Importance; really a critical issue (data corruption, freezes ...).
Comment 15 Steve Kelem 2013-02-02 23:59:40 UTC
The bug shows up when Record changes is on, even if show changes is off.
Comment 16 Steve Kelem 2013-02-03 00:31:52 UTC
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.
Comment 17 tommy27 2013-08-16 13:34:37 UTC
is anybody still experiencing this bug with recent LibO 4.0.4 or 4.1.0 releases?
Comment 18 tommy27 2013-09-07 07:03:19 UTC
(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.
Comment 19 Björn Michaelsen 2014-01-17 09:58:25 UTC Comment hidden (obsolete)
Comment 20 stragu 2014-02-12 08:14:47 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Comment 21 tommy27 2014-05-12 19:36:35 UTC
bug still present in 4.2.4.2
moving to mab4.2 list since 4.1.x is EOL
Comment 22 tommy27 2014-12-07 20:20:03 UTC
bug still present in 4.3.4.1
moving to mab4.3 list since 4.2.x is EOL
Comment 23 Adam 2015-08-28 15:11:25 UTC
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.
Comment 24 Andrey Skvortsov 2016-06-23 13:45:18 UTC
I confirm the issue too, still present in LO 5.1.4 (amd64 Windows 7 and GNU/Linux)
Comment 25 Justin L 2016-09-08 08:48:41 UTC
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.
Comment 26 Xisco Faulí 2017-09-29 08:49:30 UTC Comment hidden (obsolete, spam)
Comment 27 Michael Stahl 2018-04-11 15:10:49 UTC
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.
Comment 28 Commit Notification 2018-04-11 15:12:55 UTC
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.
Comment 29 Commit Notification 2018-04-12 08:56:45 UTC
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.