Apache OpenOffice (AOO) Bugzilla – Issue 40848
Assertion after opening .sxw containing marginal frames
Last modified: 2013-08-07 14:38:26 UTC
Hi! I have been a programmer (assembler, C, C++) since the 60's, so I will try to give you the most useful information I can. First, I cannot tell you how to create this problem, but I have attached a 30K file that contains the problem. It will show up within seconds of opening the file. Here is how it first manifested itself: 1. I was doing some simple editing -- modifying existing text and adding new text, nothing exotic -- when the program seemed to quit responding to key strokes. Actually it was still responding, as the text would suddenly appear after several seconds, or if I moved the mouse it would appear immediately. Using Windows Task Manager showed that soffice.exe was taking up 95+% of the CPU time. If I moved the mouse the CPU usage would drop, then climb back up. 2. I saved what I was doing, and then tried to scroll the page up so I could see more of it in the editing window and the program froze at 95+% CPU usage, but now without responding to mouse moves. I had to use Task Manager to terminate it. To reproduce the problem, simply load the file; it will open at the problem point. If you first load Task Manager you will notice that CPU usage for soffice.exe ramps up over a couple of seconds to 95+% and stays there until you move the mouse, and then ramps up again. Try typing something after this happens. The first letter or two may appear immediately, but then it will stop and will take several seconds for more to appear, or it will appear immediately if you move the mouse. Press page down and the program will freeze. If you load the file and press Ctrl+End you will be taken to the end of the file. Use page up to return to the page 10/11 boundary and as soon as you try to cross that boundary the program will also freeze, ie, attempting to cross that boundary from either directly will make the program nonresponsive. At first I thought this was a problem with 1.1.4 (since I had downloaded and installed it just yesterday), so I uninstalled it and reinstalled 1.1.3, but it exhibits the same behavior. I opened the file without doing any navigation in it, pressed Ctrl+A, Ctrl+C and then clicked the new file icon in the tool bar. I then pressed Ctrl+V and all the information appeared in the new file, minus some formatting elements, such as column widths, etc (not a problem), and I could navigate with no problems through the entire copied document. The problem does not show up with any other of several related, ie, similarly formatted, files that I have tried (this file is one chapter of a book). My system setup is WinXP Pro, SP 1, a 1GHz Athlon with 512MB memory, 120GB total disk space (about half empty), and dual monitors using a Matrox G450. I also have RedHat Linux on my system, but have not tested this problem on it. As a programmer this appears to me to be a rather severe, if rarely occurring, bug, so I set the priority level at P5. I wish you luck in finding and fixing it! Now, if I can remember how to hook an attachment to this...... Sincerely yours, Bob McCurdy
Created attachment 21628 [details] File that causes word processor to lock up and become nonresponsive, requiring Windows Task Manager to terminate it.
MRU->OD: IMO this is worth fixing in 1.1.5 (works good with 2.0). The document contains maginal frames and some frames with content used as headings. I think, that the problem is to be found somewhere there.
I can't reproduce the described behaviour with OOo 1.1.3, OOo 1.1.4, SO 7 PP3 and SO 7 PP4. Loading of the given document works fine. Also scrolling and editing is no problem. I didn't recognize any abnormal cpu usage during these actions. OD->MRU: please verify and close this issue.
even with OOo 1.1.0 and SO 7 the given document doesn't make any problems
I also cannot reproduce a loop in OO 1.1.4 anymore. MRU->FME: When opening this in 680m90 I get an assertion "invalid max leading". Could it be that this fact may lead to a loop on certain systems?
FME->MRU: No, "invalid max leading" is an assertion from the linguistic component. Please clearify with TL if it is of any importance.
MRU->TL: please have a look, if the Assertion "invalid max leading" is somehow critical here. Thanks!
The assertion is because it was tried to find a hyphenation position for the word "love" that was to located after the end of the word. Since there is no meaning to it the assertion was shown. The result is still Ok since no hyphenation position is returned. I couldn't reproduce any of the other problems, namely the high CPU usage. Thus the only task left is to take care of the assertion. As discussed with MRU target will be set to OOo later.
.
As for the CPU freeze. A possibel reason may be that prior to SRC680 m91 the linguistic was always updating its configuration. And with 25 languages installed on my machine this takes about 8 seconds where nothing else can be done. With a smaller set of languages (e.g. 6 as in SO7) the problem did not exist at all. If your document was saved with automatic spellchecking enabled spell checking the first word would implicitly have triggered that mechanism. See issue #43873# as reference. It now updates the configuration the very first time the linguistic is used after the office was *installed*, or if new data files for the linguistic are provided or existing one updated. That is, basically if anything in share/dict or share/dict/ooo changes it will again some time when the linguistic is first used after next office start.