Apache OpenOffice (AOO) Bugzilla – Issue 107775
oo.org extremely slow upon opening a particular (damaged?) document
Last modified: 2017-05-20 11:15:39 UTC
opening a specific document (contains lots of comments and recorded changes) oo.org becomes extremely unresponsive and it can be barely closed. happens both with 3.1.1 and m67. this is quite unfortunate, as i'm locked out of a document with a deadline already missed... confidential document will be sent to mru
document sent. for the record, slowdown happens both with changes displayed and hidden (that can even be switched sometimes, after a long wait).
seems to be caused by a large amount of hidden graphics (which might be just copies of the existing ones ?) what's interesting, cutting out tect starting with the heading "Configuring e- mail parameters" leaves lots of these duplicate images suddenly visible in the document. couldn't test much more as it's still awfully slow.
sorry for spamming the issue, but i'm discovering new facts :) after cutting out half of the doc, image count went down and the other half can be edited just fine. so there are two problems. 1. oo.org messed the document up, creating these image entries (i verified the original, it does not have such any invisible images); 2. it still would be nice if it could handle the mess it created and not slow down to become unusable... i tried increasing image cache considerably, but that doesn't seem to help.
i managed to "fix" the document by unzipping and editing xml. it seemed to me that one image was listed in edit history many, many times.
Closed due to comments from richlv Mon Dec 21 09:01:12
i'd like to ask for reopening. i just had another document get corrupted like that (with m68). so there are two issues here : 1. oo.org inserting lots of useless, redundant change information... 2. ...which it can't handle itself later. it would be most important to find and fix the cause of the first, and, if possible, make it more efficient for the second.
this just happened _again_. i would consider this a blocker as it can result in dataloss. i'm reverting to 3.1.1 myself, hopefully this problem won't be in that version.
for the record, i decided to try 320m8, just in case. it broke my document just like m67/68 did. downgraded back to 3.1.1, so far editing seems to be fine. so this issue will affect 3.2 as well, and i believe it is quite serious. for me, it seems to be provoked by deleting some things with change recording enabled. deleting some text (either with del/backspace, or starting to type with text selected) results in slower and slower operations, and in the xml file i can find lots and lots of redundant image deletion entries (even though i haven't deleted any images). in the first case it was single image repeated, in the second case there were two images alternating in the entries.
@MRU: did you get richlv's document? Canyou please have a look?
Created attachment 66974 [details] xml excerpts of repeated information
i just attached an excerpt from content.xml which shows few starting instances of repeated entries. repeatings are always twice in this file. nuking them to leave only one entry of each fixes the document. so far this has happened in two different documents as well.
MRU->OD: problem is reproducible when you open it and try to scroll through it. Somewhere when reaching page 12 you will notice that Writer will be stuck for about a minute. Because it is not (like) a crash Prio is P3.
Reset assigne to the default "issues@openoffice.apache.org".