Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||oo.org extremely slow upon opening a particular (damaged?) document|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description richlv 2009-12-18 17:35:38 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
Comment 1 richlv 2009-12-18 17:46:35 UTC
document sent. for the record, slowdown happens both with changes displayed and hidden (that can even be switched sometimes, after a long wait).
Comment 2 richlv 2009-12-18 18:18:48 UTC
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.
Comment 3 richlv 2009-12-18 18:41:25 UTC
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.
Comment 4 richlv 2009-12-21 09:01:12 UTC
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.
Comment 5 Rainer Bielefeld 2009-12-25 18:27:03 UTC
Closed due to comments from richlv Mon Dec 21 09:01:12
Comment 6 richlv 2010-01-04 14:19:45 UTC
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.
Comment 7 richlv 2010-01-04 14:29:39 UTC
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.
Comment 8 richlv 2010-01-04 15:28:09 UTC
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.
Comment 9 eric.savary 2010-01-04 15:39:58 UTC
@MRU: did you get richlv's document? Canyou please have a look?
Comment 10 richlv 2010-01-04 15:53:36 UTC
Created attachment 66974 [details] xml excerpts of repeated information
Comment 11 richlv 2010-01-04 15:54:56 UTC
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.
Comment 12 michael.ruess 2010-01-04 16:18:41 UTC
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.