Issue 40848 - Assertion after opening .sxw containing marginal frames
Summary: Assertion after opening .sxw containing marginal frames
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: OOo 1.1.4
Hardware: All Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2005-01-18 04:24 UTC by bmccurdyatpovn
Modified: 2013-08-07 14:38 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

File that causes word processor to lock up and become nonresponsive, requiring Windows Task Manager to terminate it. (29.50 KB, application/vnd.sun.xml.writer)
2005-01-18 04:27 UTC, bmccurdyatpovn
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description bmccurdyatpovn 2005-01-18 04:24:32 UTC
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
Comment 1 bmccurdyatpovn 2005-01-18 04:27:26 UTC
Created attachment 21628 [details]
File that causes word processor to lock up and become nonresponsive, requiring Windows Task Manager to terminate it.
Comment 2 michael.ruess 2005-01-18 13:58:53 UTC
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.
Comment 3 Oliver-Rainer Wittmann 2005-03-23 09:52:48 UTC
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

OD->MRU: please verify and close this issue.
Comment 4 Oliver-Rainer Wittmann 2005-03-23 09:58:21 UTC
even with OOo 1.1.0 and SO 7 the given document doesn't make any problems
Comment 5 michael.ruess 2005-04-05 10:02:00 UTC
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?
Comment 6 frank.meies 2005-04-08 15:25:19 UTC
FME->MRU: No, "invalid max leading" is an assertion from the linguistic
component. Please clearify with TL if it is of any importance.
Comment 7 michael.ruess 2005-04-21 12:10:07 UTC
MRU->TL: please have a look, if the Assertion "invalid max leading" is somehow
critical here. Thanks!
Comment 8 thomas.lange 2005-04-21 13:05:29 UTC
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.
Comment 9 thomas.lange 2005-04-21 13:05:45 UTC
Comment 10 thomas.lange 2005-04-21 13:17:03 UTC
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.