Created attachment 62989 [details]
Sample ODT file for which the problems occur

Can't repro crash or high resource consumtion with m49 on WinXP - RAM, VM and 
CPU usage is not out of ordinary.
I suggest sending your 11MB .odt to mru@openoffice, putting issue number in 
the subject.

I can't sent the whole 11 MB file due to contractual obligations.

By "not out of ordinary", what are your numbers compared to other odt documents?

If it helps, I'm on an Intel P3.

Does anyone have a link to documentation on how to get a stack trace for
OpenOffice using WinDbg?

Thanks

Created attachment 63018 [details]
memory usage: circled in red is 3.1, circled in green is 2.31.

Page Downing to the end increases mem usage to 140MB combined for 3.1 and 
170MB combined for 2.3.
For trace generation you would be better answered in dev@openoffice list.
You can clean out your 11MB doc via
Ctrl+F, 
More options, 
RegEx, 
Find ([:alnum:]), 
Replace X

The 11 MB file contain many images representing a lot of information I am not to
divulge; thus, even with your suggestion, I can't attach the file.

I may just have to wait for someone with an Intel P3 to verify.  I'm beginning
to suspect this may be an architecture-specific bug.

Since I cannot find information on debugging OOo with WinDbg, I decided to debug
without anyway, and without symbol files, as I could not find info on obtaining
those either.

An exception that occurred on opening the attached odt file is:

(988.a3c): C++ EH exception - code e06d7363 (first chance)


Here is the stack trace on crash:
---------------------------------
eax=014aef60 ebx=00000000 ecx=00000000 edx=00000001 esi=014aefe8 edi=083ebefc
eip=7c812afb esp=014aef5c ebp=014aefb0 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for
C:\WINDOWS\system32\kernel32.dll - 
kernel32!RaiseException+0x52:
7c812afb 5e              pop     esi
Missing image name, possible paged-out or corrupt data.
Missing image name, possible paged-out or corrupt data.
Missing image name, possible paged-out or corrupt data.
2:002> kp
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for
C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375\MSVCR90.dll
- 
ChildEBP RetAddr  
WARNING: Stack unwind information not available. Following frames may be wrong.
014aefb0 7857dbf9 kernel32!RaiseException+0x52
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for
C:\Program Files\Editors\OOo-dev 3\Basis\program\svxmi.dll - 
014aefe8 574d4fca MSVCR90!CxxThrowException+0x48
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for
C:\Program Files\Editors\OOo-dev 3\Basis\program\swmi.dll - 
014af02c 5cd77267 svxmi!SdrObject::getShapePropertyChangeNotifier+0x6e
014af06c 5cd2fe20 swmi!SwFlyDrawContact::MoveObjToInvisibleLayer+0x1427
014af09c 5cd30fc6 swmi!SwModify::Modify+0x63
014af0e8 5cd8357c swmi!SwFmt::Modify+0x15d
014af110 5cd31123 swmi!SwFrmFmt::Modify+0xe1
014af1a0 5cf7d594 swmi!SwFmt::SetFmtAttr+0xb8
014af208 5cf7dbad swmi!SwDoc::GetRedoIds+0x9e71
014af218 5cf742b9 swmi!SwDoc::GetRedoIds+0xa48a
014af290 5cf74e2e swmi!SwDoc::GetRedoIds+0xb96
014af2b0 5cf7974a swmi!SwDoc::GetRedoIds+0x170b
014af398 5cf72c1c swmi!SwDoc::GetRedoIds+0x6027
014af3b8 5cd47785 swmi!SwDoc::Undo+0xb9
014af400 5d1154e0 swmi!SwEditShell::Undo+0x117
014af41c 5d08de1e swmi!SwWrtShell::Do+0x67
014af438 5d08f854 swmi!TextControlCombo::Disable+0xd91
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for
C:\Program Files\Editors\OOo-dev 3\Basis\program\sfxmi.dll - 
014af444 58170bff swmi!TextControlCombo::Disable+0x27c7
014af518 5817261a sfxmi!SfxDispatcher::Call_Impl+0x3ff
014af578 5816bc2c sfxmi!SfxDispatcher::_Execute+0x1c5

@Punisher: send me the document via e-mail mentioning the issue ID in the
subject line.
I am a SUN employee so as soon as you send me the file, your "contractual
obligations" concerning confidentiality become ours. :)

@punisher: again, please send me the file or a link to it privately. Adding
debug info here does not help - and makes the description unreadable - because
writerneedsconfirm is *in general* read by people who are not able to interpret
debug info AND this still does not make the problem reproducible on our side.

If I can reproduce the problem manually, then I'll analyze the problem forward
to our developers who can then debug.

Else this issue could right now be closed as WORKSFORME.

@es:
What email address should I send it to?  I notice that even for me, the email
address here appears as userid {at} openoffice.org.

The document must under no circumstances end up on the Internet.

Yes, my login name @openoffice.org.
No, private e-mails don't go on mailing list archives! ;)

@es: Document sent.  Hopefully the server supports the attachment size. :-)

Anyone able to reproduce this issue yet?

No crash on Vista using your document as described.

#1: The crash is only one of two issue.  The crash might be P3-specific.  How is
OpenOffice using SSE2?  That at times is a source of crashes for older CPUs.  Is
anyone able to test this on a P3 or non-SSE2 capable Athlon?

#2: What about the memory leak?  Were you able to verify that?

Thanks

With hte attached document I can see heavy memory consumption but no crash.
The stack above tells something about drawing objects. Are there any drawing
objects in the original file?
ES, can you show me the original document on Monday perhaps?

@mru:

The crash is not directly related to opening of the file (only indirectly in
that OpenOffice is not properly handling something in the file).  To reproduce
the crash itself, you must follow steps 1 to 6 in the bug description.

As for drawing objects, no.  There are no drawing objects in that file.  The
only possibly related thing is that I had to change properties (size, position,
etc) of some of the images I pasted.

I originally filed Issue 102627 but it got duped to Issue 102380 and there it
was asserted that the issues I witnessed in 102627 were not related because
"Writer has it's own implementation of Graphic objects (and it's own
buffering/caching mechanism)."  That might give you some more clues.

But again: a Pentium 3 (or Pentium M) + Windows XP SP3 might be necessary to
reproduce the crash, if you can't reproduce following my steps.

Sorry for just cross reading the description, the summary confused me a little
bit. Crash is reproducible with the attached sample.

MRU->OD: Open attached document, select the whole content of the last page (not
only the graphic), delete, Undo -> C++ runtime error. Maybe it is the same root
cause as issue 102752 ("Writer crashes if you change the anchor of a drawing
object")?

Unfortunately, by renaming this bug, you're losing the memory leak issue, which
is a very significant issue itself.

If you prefer, I can create a new bug with only the memory leak issue and make
it block this bug, since discussion on it has already occurred here.  Once the
memory leak has been acknowledged as a NEW issue, I can then remove blocking.

The crash does indeed appear to be Issue 102752, so I've commented there and I'm
changing this bug back to focus on the memory leak.

Confirming that the crash is the same as issue 102752

It reveals that the given document contains graphics which are represented by
the Writer implementation for graphics and graphics which are represented by the
Drawing Layer implementation for graphics.

My investigation of the memory footprint reveals the following:
- The memory usage screen shot from kpalagin confuses me. It shows that 3.1
consumes less memory than 2.3.1 - 21 MB vs 50 MB
- OOo 3.0 on my system consumes around 120 MB after opening the attached
document and having displayed all pages on the screen. Closing the document
bring the memory consumption back to around 70 MB. Reopen and closing reveals
again in a memory consumption of around 70 MB.
- OOo 3.1 on my system consumes around 114 MB after opening the attached
document and having displayed all pages on the screen. Closing the document
bring the memory consumption back to around 67 MB. Reopen and closing reveals
again in a memory consumption of around 67 MB.
- DEV300m54 on my system consumes around 127 MB after opening the attached
document and having displayed all pages on the screen. Closing the document
bring the memory consumption back to around 81 MB. Reopen and closing reveals
again in a memory consumption of around 81 MB.
Thus, I can not reproduce any serious memory consumption or memory leak
regarding the given document.

Any further detailed results on the memory footprint?
Re-target to OOo 3.x and lower the priority to P3 until further investigations
reveals a serious memory consumption or memory leak.

I have found that 2.3.1 consumes less of for both RAM and Virtual memory than 
3.1, but the difference is minor.

1. Maybe es could chime in, since I sent him the full document and I've yet to
see any response regarding tests on that document.

2. Also, none of you are revealing what platform you are testing on: CPU brand
and model + operating system.

3. Notice I was specific about my platform and that could also be a contributing
factor.

I have performed my investigation under Microsoft Windows 2003 Server on
dual-core AMD processor with 16GB RAM. The memory footprint will vary from
system to system. But from my point of view that is not the point.

The general memory footprint for the given document is high, because of all the
large embedded PNG graphics. For another document of a similar size on the file
system the memory footprint can be larger or smaller - it depends on the
content. But this is no defect from my point of view.

The defects which I got from the description are
- the memory consumed by a certain document is not released after closing it
- the same document consumes much more memory in OOo 3.1+ than in former version
of OOo
I did not reproduce these defects - that is what I want to show with my
investigation results.

@od: If you're a Sun employee, ask es for the document I sent him.  Test with
that and you're likely to see the issue.

It is a defect.  Once someone compares results for the document I sent to es,
between OOO 3.0 and OOO 3.1+, the extent of the problem should become apparent.

My investigation of the memory footprint with the confidential document given to
ES reveals the following:
- The document is similar to the attached one, but it has more pages (82 pages
in my environment).
- OOo 3.0 on my system consumes around 417 MB after opening the attached
document and having displayed all pages on the screen. Closing the document
brings the memory consumption back to around 71 MB. Reopen and closing reveals
again in a memory consumption of around 71 MB.
- OOo 3.1 on my system consumes around 422 MB after opening the attached
document and having displayed all pages on the screen. Closing the document
brings the memory consumption back to around 77 MB. Reopen and closing reveals
again in a memory consumption of around 77 MB.
- DEV300m54 on my system consumes around 436 MB after opening the attached
document and having displayed all pages on the screen. Closing the document
brings the memory consumption back to around 91 MB. Reopen and closing reveals
again in a memory consumption of around 91 MB.
- In OOo 3.1 I noticed that the memory is already consumed during the opening,
while in OOo 3.0 and in DEV300m54 (OOo 3.2 code line) the memory is consumed on
displaying all pages. Thus, in OOo 3.1 it seems to that all embedded graphics
are already loaded when the document is opened. This also seems to cause that
the opening process in OOo 3.1 takes longer than in OOo 3.0 and DEV300m54. But,
this seems to be corrected already on the OOo 3.2 code line.

Hmm.  Your results for 3.0 are strange.  Is it a clean installation?

On my system, memory consumption for 3.0 is around 100 MB and the document loads
quickly (within seconds).

With 3.1+, memory consumption is well over 300 MB (don't remember exactly how
high), CPU is pegged, and it takes a few minutes to load.

Note: I don't use quick starter.

Yes, my installation is a clean one.

Did you noticed what I have said about the different behavior of OOo 3.1
compared to OOo 3.0 and DEV300m54?
- Loading the document in OOo 3.1 takes more time then in OOo 3.0 and DEV300m54.
On my system the values are 12 seconds vs. 6 seconds from confirmation of Open
File dialog until display of first page. (Note: I have 16GB RAM and a fast hard
drive in my system.)
- Directly after the load OOo 3.1 already consumes the "complete" memory, while
OOo 3.0 and DEV300m54 consumes only part of it. On my system OOo 3.0 consumes
around 73 MB directly after load having displayed only the first page.
- After having displayed all pages of the document on the screen in OOo 3.0 and
DEV300m54 the "complete" memory is consumed.

OK, but isn't it desirable to make OOO faster rather than [significantly]
slower?  The statement: "But this is no defect from my point of view," suggests
to me that this issue is considered not worth remedying.

Anyways, I hope otherwise.

Thanks

od->punisher:
My statement refer to OOo's behaviour that it has a high memory consumption for
documents with large content.

For me with issue it about:
- the memory consumed by a certain document is not released after closing it
- the same document consumes much more memory in OOo 3.1+ than in former version
of OOo
I am right about this?
These defects I can not reproduce.

The defect I have observed in my investigations is that in OOo 3.1 directly
after load all the memory needed for the document is consumed. This defect has
been already fixed on the OOo 3.2 code line (I have tested DEV300m54).

I have now tested with DEV300m55.  Initial loading is now faster and only about
114 MB of memory is consumed.  I suppose this is the part you say is fixed by
DEV300m54.

However, after settling for about a second, memory consumption steadily
increases.  CPU utilization also goes up considerably, for the duration, but not
as bad (i.e. interface now responsive, but laggy) as before (app' unusable for
minutes).  This goes on for about 90 seconds--until all graphics are loaded. 
Once completely loaded, VM Size sits at 422 MB.  Keep in mind, I have a 933 MHz
P3 with 512 MB RAM running Windows XP SP3.

Like I stated, 3.0 had no problems with the document.  In fact, it was with 3.0
that I composed the document.  I most certainly did not see what I'm seeing now.

The situation is nevertheless better now, but improvements would definitely be nice.

Thanks

Evaluation of the described defects in OOo 3.3. The described defects are:
- the memory consumed by a certain document is not released after closing it
- the same document consumes much more memory in OOo 3.1+ than in former version
of OOo

My results:
Still no confirmation of these defects.
From my point of view this issue can be closed.

od->punisher and mru:
Please also evaluate again in OOo 3.3.

I checked with DEV300m100 now (on Win7 native). soffice consumed about 86 MB
after opening. This did not increase even after I scrolled through the whole
document.

resolving as worksforme and closing it

closing