cannot load it at all in 644_m11

Reassigned to MRU

MRU->DVO: at the end of the import the assertion "PageDescs
überindiziert". Please evaluate if this is caused by the core or the
filter.

dvo->cmc: There's a problem in the RTF-filter. On first look, things
broke after CWS jollyfilterteam05 integration. :-/

At the end of 

    void rtfSections::InsertSegments(bool bNewDoc)

the following code (swparrtf.cxx#1067)

    myDummyIter aDEnd = maDummyPageNos.end();
    for (myDummyIter aDummy = maDummyPageNos.begin(); aDummy != aDEnd;
++aDummy)
        mrReader.pDoc->DelPageDesc(*aDummy);

wants to delete page descriptors that don't exist. (It tries to delete
 the sixth PageDesc of five.)

I find the code a bit weird anyway, since 

   void SwDoc::DelPageDesc( USHORT i )

gets a numeric argument, but the numbers are just indices which of
course change during the deletion. Without adjustments in the loop,
this would only seem to work if maDummyPageNodes contains only one
element or was sorted in decreasing order.

cmc: Yes. Was fixed in soberfilterteam06. Will check and confirm this
in a post soberfilterteam06 integration installset.

cmc->dvo: In SRX645m2 the rtf bug is fixed, and now it hangs/crashes
back in pagination after lots of looping louie's. In the 1.0.1 the
code which was introduced in filterteam05 and fixed in filterteam06
didn't exist, so the original problem must the one that is now visible
again in SRX645m2

649 pages, huge amount of footnotes.

dvo->fme: Looping Louie (after SRX645m2). Strangely, this is targetted
at OOo 2.0.

*** Issue 14074 has been marked as a duplicate of this issue. ***

I'm going out on a limb here and changing the target release to
ooo1.1rc on the theory that all known crash bugs could/should
be fixed for ooo1.1.  If I'm wrong, and this crash bug requires
a major rewrite to fix, please mark this bug as ms_interoperability
when you change the target back.  Thanks...

FME: There are at least two loops caused by this document. I found a
potential fix for one of them. Unfortunately there is still the other
loop, which seems to be quite evil. There is no easy, low risk fix for
that one. As discussed with SBA, I set this back to OOo 2.0.

.

FME: Wow, that was a hard one. After a couple of fixes the document finally
opens. Well, formatting it takes quite some time, but after saving it as *.sxw
file, formatting will be much faster.

sw/source/core/layout/flowfrm.cxx rev. 1.40.20.2
sw/source/core/layout/wsfrm.cxx rev. 1.56.20.2
sw/source/core/text/frmform.cxx rev. 1.50.20.1

.

Ready for QA.

.

Checked fix in CWS swqbugfixes04.

Checked in 680m52. Closed.

I have just downloaded 680_m65, and noticed the following odd effect.  The first
time I open the document (Pan123.rtf), the first page is displayed, but the
program continues with very high CPU usage indefinitely (> 45 minutes Pentium 4
3.0 GHz).   If I close openoffice, and start it again, I do not get the high CPU
use after loading.  Deleting the ~/.openoffice.org1.9.65 directory makes the
effect return.

I have also noticed huge variation in times for the document to load between
machines:  Pentium M 1.2 GHz, 1GB RAM = 6.5 minutes; P4 2.6 1GB = 7.5 minutes,
P4 3.0 2GB = less than one minute.  Memory may not have been a factor however,
as the P4 2.6 had a reported ~500MB free memory during loading. 

Yes I also could see the problem with 680m65 or m67. But with newest m69, it
works. I checked this with internal build, which will be released soon.

Closed.

I have just downloaded 1.9.100-1; the problem of indefinite load time on first
load remains for Pan123.doc.  Note, as before, that killing and restarting OO
resolves the problem, and removing my .openoffice directory causes the problem
to return.

Could you please submit a new issue for this, so that this one won't become too
complex here (will be VERY uncomfortable too handle properly). Thanks for your
patience.

Please also attach the "offending" document, because the above mentioned link is
not valid anymore.