Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | OO +/- system lockup with scroll, save of doc with many footnotes | ||
---|---|---|---|
Product: | Writer | Reporter: | matthewbrett <matthew.brett> |
Component: | code | Assignee: | michael.ruess |
Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | issues |
Version: | OOo 1.0.2 | Keywords: | ms_interoperability, oooqa |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
matthewbrett
2003-01-21 13:52:24 UTC
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. |