Apache OpenOffice (AOO) Bugzilla – Issue 70268
Writer hangs "idle formatting" specific document containing many tables and objects
Last modified: 2017-05-20 11:15:45 UTC
I have a 349-page odt file (private-- Can be shared, but please do not post it here). OOo 2.0.4 RC1 hangs within five minutes of normal operation, such as editing paragraphs. Specifically, updating index (or the "Update all" command) is impossible, as Writer invariably hangs. What I mean by "hangs" is, the mouse pointer turns into hourglass, and then the application does not do anything, even after half an hour. When I move the mouse, the pointer moves, but it remains hourglass shape until you take it to the red X ("close this window") button in the window's bar. The only function it allows is to click on this "close window" button. But if I close the window, Window pops up its "this application does not respond" dialog. Another visible sign when Writer hangs is, a small part of the screen turns white. The rest of the screen looks normal. I could work normally on the same file with 2.0.3; although earlier versions used to CRASH (i.e., vanish altogether; not "hang" as described here) frequently.
Some additional observations (based on more hangs): 1. If I happen to switch to another application while Ooo is active, then switching back is impossible (I can't ALT+TAB to OOo). At other times I can come back, but all I see is a all-white screen. 2. Scrolling rapidly with mousewheel also seems to trigger the hanging. Even a completely unedited file can hang. 3. All panes (including Navigator and Styles pane) flicker heavily when the document is opened. The total number of pages also changes for the first few minutes (by 3-4 pages). Finally, after a few minutes, this lessens (but does not entirely cease). I have reported this before also; and I feel this is related to the hanging/crashes. 4. The CPU reaches 50% on this HT-enabled P4 3-GHz PC. There is no other application running which can load the PC. Other parameters: commit: 540 MB. private bytes: 52 MB. 5. Restarting of PC has no effect.
As usual ;-) please send the document to mru@openoffice.org. Thanks a lot!
:) Sure! Sorry I could not isolate the problem by truncating the document. This must have crashed at least 15 times today. I even uninstalled OOo, rebooted the PC , deleted the installation directory entirely, and then installed OOo all over again. That also didn't make any difference. (using Win XP SP-2).
Tried on RC3 also. I can't even open it mostly (OOo shows an all-white screen till I forcibly close OOo); and sometimes it crashes soon after opening.
Some more observations: 1. I have sent a lot of recovery wizard reports to OOo team earlier. But OOo 2.0.4 RC3 does not create a report after recovering the document (when I press the NEXT button in the recovery wizard). How can I start generating reports again? 2. The "white patch" I mentioned in earlier post in this bug is actually caused by a floating "table" toolbar. When OOo stops responding, this toolbar vanishes and leaves behind a white rectangle. I tried with other floating toolbars, and they too had the same effect when OOo hanged.
MRU->OD: open the (confidential) bugdoc and leave it open for a while -> Writer loops Starting "Tools.Update.Page formatting" manually after opening seems to workaround the problem at first.
Yes, confirmed: Manual page formatting avoids hanging. It also confirms two observations in my second post: (a) The "total pages" number settles instantly, and does not change afterwards. (b) The heavy flickering in all panes stops immediately. Now the document seems to be at peace with itself! :) I will let you know if the document hangs AFTER some time.
yes, RC3 DOES hang even if I use the "update page formatting" command. But it happens after a long time, which allows me to do at least SOME work. In preparation of the eventual hanging, I have to keep saving. Each save takes about a minute. I have to abandon the work done after the last save and the hang, because once I got hard-coded addresses in all hyperlinks of a recovered document; and I don't want to have that problem on my hands again. **** Anyway, whatever factor it is, there is a clue: 2.0.3 was better than 2.0.4 RC1. 2.0.4 RC1 was better than RC3. RC3 is the worst: If I don't use the "update page formatting" command, it hangs so fast that I can't do any work at all. So a code-comparison will lead you to the problematic code.
Investigation reveals, that the layout algorithm has problems with table, which is named "Table21" I've made some minor changes to the document to avoid the layout loop: - clear "Keep with next paragraph" attribute at the paragraph before table "Table21". - insert manual page break at paragraph following table "Table15". - change anchor type of graphic "graphics749" to as-character. This document doesn't causes trouble to the layout algorithm. OD->raindrops: I will send you the changed document via eMail
Thanks! I have several points: 1. Although you have changed the document to avoid trouble, I cannot see any connection between the problem and what you did to the document. As a result, I may easily land in trouble once again; because this document is under active editing; and I may do something that causes the same problem again. Could you tell me how you could spot the troublesome parts/properties; and how your suggested remedies work? 2. The algorithm definitely needs correction; so that it does not react to specific formatting in this way. Even if a document is badly formatted, it should not become unstable. 3. Specifically spreaking of the anchoring of an image as a character, I have raised another bug that talks about an image jumping out of a table's cell. I had to drag it back often. Finally I tried to anchor it as a character, and it stayed in place. Is that what you saw in this case? 4. In my document, many (inner) tables have text with "keep with the next paragrph" property, although I have not selected it deliberately. I noticed this aspect when I saw that some tables had skipped blank space on one page to be on the next page; without an apparent reason. Is there some bug, or an overlooked aspect that turns this property ON without my knowledge? If yes, how do I avoid that? Thanks once again!
ad 1. Too much unneccesary "Keep with next paragraph" attributes stresses the layout algorithm, if the group of paragraphs and tables, which wants to keep together, are larger than one page. Especially, when the tables span over more than one page and contain anchored objects. Thus, it is better to avoid such large keeping groups and instead insert manual page breaks, if needed. These are my first two changes to the document. The third change is special to anchored objects inside table cells. The anchored object overlaps with its anchor and the anchor has to wrap around the anchored object. The text wrapping causes the anchor to move to the next page. Thus, the anchored object has to follow its anchor. If now the table, which contains the anchor, is formatted again because of an insufficiency of the layout algorithm or because it's needed to fulfill a keeping, the anchor is moved back to the previous page --> potential layout loop. We are trying hard to consider all such cases in the layout, but we aren't perfect. ad 2. Correct. We are constantly working on improvements/corrections of the layout algorithm. Thus, I will also fix this problem, soon or later. The changed document only "workarounds" the problems and I provided it, so you can continue to work on it. ad 3. As I see, the document is created by importing a Microsoft Word document and in Microsoft Word anchored object are allowed to leave the table cell. Thus, I've implemented this behavior for OOo 2.0 To keep an anchored object inside a table cell: - Check attribute "Follow text flow" at the anchored object, or - change the anchor type to as-character, if possible. ad 4. I think this attribute is set on the Microsoft Word import. If this attribute of a certain table changes not intended, it's a defect. If your can reproduce such a attribute change, please submit an issue.
Thanks for the detailed answers. Yes, I have actually SEEN this, in the same document. But that case was slightly different-- I had TWO images there: I had inserted a screenshot from files; and then drawn an ellipse over it to highlight a particular button. I saw that the ellipse was "chasing" the screenshot across the page break, to-and-fro! However, this lasted for only a few minutes; and after that they stopped moving (perhaps the repagination in earlier pages shifted them both in the middle of the page.) I have often noticed that such ellipses shift to one side; and no longer encircle the correct part of the screenshot. Probably this is due to the anchoring+wrapping problem. Yes, this document was imported from Word (but that was a LONG time ago). I will simulate the Word import and see if a spurious "keep with the next paragraph" attribute is added. Haven't received the file yet; but I think I can manage it now. In fact, I need to remove the "keep..." attribute from most of the paragraphs! Thanks once again!
Just found something: MRU wrote in response to issue 60632 (which I raised earlier): "Currently the "keep with next paragraph" option does not work inside table cells (the evaluation does not consider the attribute inside table cells)." Our current observation is just the opposite! How can both defects coexist?
OD, Somehow the file hangs as soon as it opens; even with RC1 (which was better than RC3). Earlier OOo was at least allowing me to edit for a few minutes. No more. :( When you said you'd send the file, I thought I can manage. But now I have no choice but to use your modified file. Could you send to me through email please? I noticed that 2.0.4 Final is available. Does that have (somewhat) corrected algorithm? Then I will try that. Thanks in advance!
OD->raindrops: ad your comment about issue 60632: It is correct, that the "keep with next paragraph" attribute isn't cosidered inside table cells. For this layout-loop issue the "keep with next paragraph" attribute inside table cells doesn't make trouble.
OD->raindrops: ad your last comment of 2006-10-13: I didn't get, what's going wrong now. Do you have trouble with the changed document, I've send you via eMail? Or do you have trouble with the original document? BTW, the current RC3 equals the released OOo 2.0.4
I was referring to my own local copy. I found that MRU's trick worked well (use the "Update> page formatting" menu option IMMEDIATELY AFTER opening the document.) So I continued my work on the document. As a result, my latest document no longer matches the copy you have corrected: It contains many changes/additions. That is why I wanted to use my own copy, and correct it the same way you have described. Unfortunately, something happened during the last 3 days' work: Now none of the OOo versions (RC1, RC3, Final) can open the document in a stable manner. They do NOT respond to the "Update> page formatting" menu option: The task completes 50% to 90% and then freezes, no matter how fast I try to issue the command. So the only option left for me is to forget about all changes I made in the last 2-3 days. But I have not received your corrected copy (I checked my spam folder also). Could you send it again (to my GMAIL account) please? Thanks in advance! MRU has the correct email ID. *** When you mentioned "keep with next paragraph" as one of the root causes, I assumed that it must be inside a table, because most of my text is inside tables only. (There is hardly any text outside tables). That is because I have used a two-column table in each chapter to control the flow of the text. Only some appendix test is outside tables. So if "keep with next paragraph" property inside a table is ignored, most of the paragraphs should not cause any problem (except the appendices). Does your observation match with this?
OD->raindrops: Send me your copy of the document, probably I can correct it. *** There a lot of empty paragraphs outside the tables, which have all "keep with next paragraph" attribute set. E.g., The empty paragraphs between table "Table15 and table "Table21". What do you mean by "controlling text flow by two-columned table"? To control text flow you can use "manual page breaks".
Raindrops -> OD @"controlling text flow by two-columned table": I meant controling the text flow in columns. I use two columned table; so that the narrow left column serves as the left margin, and the wider right column serves to hold the paragraph text. When I need the full width of the page (typically to insert a large image), I just insert a row and then merge the two columns. Then below that, I continue with the two-column table layout. Most of the chapters are formatted like that; only the text in the appendices is free-flowing. That's why I thought that only the appendices can create this trouble. *** Oh now I see what you mean: To break the text-flow VERTICALLY, I do not use manual line-breaks or empty paragraphs inside the text. I use page-break or section-break. So this must be thanks to MS word-to-Writer conversion. (I will check this out, and raise a bug if confirmed.) And the strange uncontrolable movements (and gaps) that I see must be because of that, too! *** Yes, I will send the latest version tonight. Thanks! May I use your openoffice email ID (which is listed in this thread)? If you want me to send it to SUN email ID, please send me a test-email, so that I can reply to it. Thanks once again!
Raindrops->OD Although I have described the latest situation through mails, this is to record the summary with this bug, so everything remains in one place, for all people to see. 1. Although you were able to recover the document, I was not even able to open the document with the same version of OOo (i.e., 2.0.4 Final). My PC is very powerful (Pentium 4 with HT, 3 GHz, with 1 GB memory, Win XP SP-2). I have closed all other applications to avoid loading. Even then my attempts failed. DEFINITELY there is another PC-specific factor here. Could it be the Java version we use? I am using J2SE 1.5.0_06-b05.) 2. After receiving the modified document, I have selected the ENTIRE document and reset the "keep with the next paragraph" property of ALL paragraphs. But even now the document fails often. If I use the Tools> Update> Page formatting, the repagination progress bar stops and then OOo hangs. The CPU reaches a steady 50% and remains at that level. I have noticed that the progress bar ALWAYS stops at specific points (either 55% or 20%). I guess that at these points, the algorithm must be doing something that is prone to "infinite aloop" behavior. This is another issue that can be investigated. 3. Under no circumstances should an algorithm be allowed to loop endlessly. There should be a limit on the number of loops: Once that limit is reached, the algorithm should exit from the loop. Even if the document is NOT fully optimized at this point, at least the OOo does not hang, and the user can go on working! Given the choice between losing all work and an odd-looking document, I'd take the latter. 4. The anchor and image should not be allowed to enter an endless chase. They should be moved together: Once a author has arranged them in a certain configuration, Ooo has no reason to change that. Specifically, the algorithm has a problem when images are placed in/around tables, with their anchors placed INSIDE a cell. (I had to do that to stop the images from drifting away from the text. See issue 60757 for a related problem). Even here, there should be a loop counter that exits the loop after certain iterations.
OD->Raindrops: ad 2: Do you already submitted a new issue for this? If yes, please send me the issue number. ad 3: You are right on your statement about an algorithm. But, the problem here is, that the current text layout algorithm is implemented by hundreds of methods, which calls each other in a lot of manners and situations. There is on method instance that loops on the document pages to format them. Here, we have already implemented an loop control, if again and again the same pages are formatted. But, if a layout loop occurs on one page, there doesn't exists such a loop control. Thus, if I count on your statement about "looping" or "wrong layout", it makes sense to implement such loop controls in general. I will discuss this with the responsible developers. ad 4: Currently the user can arrange anchor and object into an endless chase. E.g. paragraph with tree lines and an object with wrapping style "No Wrap" and vertical position "center to paragraph text area". No solution exists for this configuration - above and below the object couldn't be the same count of text lines. In such cases the layout algorithm tries to find a compromise. If you have a concrete problem, especially when the anchor is inside a table cell, please submitt an issue - I will take care of it. For issue i60757, I only have the document created by MRU. But, you have stated, that this document doesn't show the described defect. Could you provide the corresponding document and describe, which object you want to move?
@2: I have raised Issue 70662. @4: Yes, I still have problems described in the issue i60757 in this same document. That issue was raised so long ago that I had given up. I will try to experiment and let you know the image that misbehaves in such a way. Mind you, it is very difficult to isolate the problem in a single-page document. I have seen other TWO other problems with images placed in tables: (a) The initial problem that I noticed was that the panes of the file blinked heavily. I tried going down the file to see what was happening; and I observed the following: I had a screenshot, over which I had placed an ellipse (to highlight a button). This image was crossing over to the next page, and the ellipse chased it. then the image jumped back to the previous page, and the ellipse followed it. This was repeating endlessly. (b) As you have seen in the sample document, I merge the left+right columns of a row to accommodate wide images. One such merged cell contained only an image; nothing else. The image was anchored to an inside corner of the cell. That image always jumped out when I was not on that page. I used to notice that only when I returned to that page (or when I fired a pdf). Finally I changed its anchoring to as character, and it stayed put. I will see if I can repeat that. But here also I am not sure If I can create a single page sample.
Apart from the two suggestions I made in earlier post, the algorithm has many more defects: (a)Why does the algorithm launch every time I start the document, and do heavy work? (Even before entering the endless loop, it can change the total page count by 6 in my 350-page document!). I created a pdf file and sent to some reviewers. When I received their comments with page numbers, I could not make any connection, because that text in my odt file had shifted by 3 pages! The next day the text went 2 pages to the OTHER side! (b) Why does it change the "total pages" count by a different amount? If I do not do any work in the document, but simply open the document, the algorithm immediately starts working, and arrives at a different total page count! Why is it not repeatable? (c)Apparently the algorithm shifts some of the content to other pages. But even then OOo not consider the document changed! Why? (The "save" button is still grayed out.) If OOo treated this changed content as a modified file, the user would be asked to save the changed document before exiting; and then (hopefully) only a little work would remain for the next session. (d) Why is this long-duration process not ESCapable? The user should be able to terminate it by pressing ESC.
A new observation in the CORRECTED document (where ALL the paragraphs were edited to reset their "Keep with the next paragraph" property): This document was also crashing the OOo repeatedly. I tried to open the document using two different methods (described below), but got identical results: (a) Start OOo first, and then open the document from its File>Open menu. (b) From Windows Explorer, click on the document. The trick suggested by MRU (immediately run the Tools>Update>Page formatting) also failed; and the OOo kept hanging. Finally I tried a new experiment, and it seems to be working: I clicked on some nodes of the "Headings" tree in the Navigator. OOo responded well, and thereafter did not hang for a long time. But if I try to use the vertiocal scroll bar (and especially the mousewheel) to scroll down the document, it actually triggers the hanging. I think there is a clue here.
OD->raindrops: ad your comments from 2006-10-25: ad (a): The text document is stored in OpenDocument file format, which doesn't contain any layout information about the text document. Thus, after import the text document has to be formatted. ad (b): This is a defect. Can you please submit another issue for this defect? You can directly assign this issue to me and send me the document via eMail. ad (c): This seems to be also a defect. Thus, the same as for (b). ad (d): This is a good suggestion, on which I've already thought about. Please submit an issue of type "enhancement" or "feature" for this request for enhancement. ad your comments from 2006-10-30: Can you please send me the document via eMail? I apologize for asking you to submit more and more issues and asking for the documents. But, for the handling for the fixes and for the quality assurance people, it is better to have separated issues for each of the problems. Thx.
Sure- No problems at all! But if all details are already submitted in a bug, the QA people should have a policy to split the original bug themselves. Bugzilla already has bug-cloning facility. That approach would also make sure that dependency is properly recorded; which would help the developers (on the other hand, the average OOo user is not trained in using Bugzilla). Just my two pfennig. :) I will submit separate bugs and put the links here. Watch this space! I will also send the latest file tonight.
Raindrops->OD, I have raised the following issues: Issue 71028, Issue 71030 and Issue 71031. Also see Issue 60757 and Issue 70662 for related problems. Although these issues are split for ease of management, they are closely related, and should be considered together.
I've already closed issue 71030 as WONTFIX, because the OpenDocument file format can't contain layout information. Issue 71031 is from the point of view of the Writer an enhancement. Issue 71028 is still unconfirmed, because I'll wait for the document to reproduce the described defect. BTW, I can't be assured that office document look the same on each environment.
Now the document has grown to 355 pages. I was using OOo v2.1 till yesterday; and it worked stable for most part, except a single crash. After that crash, the recovered document lost formatting for some paragraphs, such as bold, superscript, etc. I had to do that once again. But apart from that one crash, everything was OK. Yesterday, I downloaded the latest version m197, Because it has enhanced options for "export to pdf", which I want to use for my manual. But this version hangs within a minute of opening the document. My trick to click quickly on the Headings in Navigator panel does not work. I am providing this feedback because from the algorithm point of view, something has changed for the worse in m197 as compared to v2.1. This could provide a clue for your investigation. Please check!
I am having a problem which sounds similar to this: I have a 300 page master document with about 39 subdocuments. It has a table of contents in the master document which runs for about 1.5 pages. The document loads fine, and I can start working but OpenOffice 2.3 hangs about 15 seconds later whether I leave it idle, or start editing. If I right-click the table of contents and go "Update table" within the first 15 seconds, it doesn't subsequently hang until I make a big change like inserting or removing a subdocument. Continually updating the TOC after every change keeps OO from hanging; but of course isn't practical. I got the idea of updating the TOC from this bug report; using "Update All" also prevents OO from hanging. Unfortunately I can't send the document as it is unpublished and very personal, but I wanted to raise the issue because hangs caused by background processing are very nasty. You're in the middle of something and then... hourglass!
according to release status meeting -> 3.x
*** Issue 93684 has been marked as a duplicate of this issue. ***
this issue is still present in a 300m15 build - 160 p document with 700+ objects. any progresses?
Sorry, no progress so far.
Reset assigne to the default "issues@openoffice.apache.org".