@reporter:
Your link lead to a 168 MB zip file containing 4MB data (or so), and it seems
that you want to tell us: "damaged document causes problems"?

Please contribute more information concerning that document,  
read our guidelines on
<http://qa.openoffice.org/issue_handling/pre_submission.html> and  
<http://www.openoffice.org/bugs/bug_writing_guidelines.html>, then
contribute a clear step by step instruction containing all observations (error
messages ...), _every_key_press_and_every_mouse_click_ how to reproduce the
problem, and explain why you believe that your results are unexpected.
That means (for example): 
 do not write something like „I am not able to ...“, but
 „6. left mouse click on …
     expected: …, colour of … changes, … 
     actual: no …., colour remains white, no …

I thought I was fairly clear that the document is crashing when I save it (I did not say 'damaged 
document causes problems') but here you go:

Step by step instructions.
1. Make any change inside the document
Expected: the change to happen
Result: the change happens
2. Either hit Cmd-S to save or left click the Save icon in the toolbar or left click on File and go to Save
Expected: the document to save
Result: OpenOffice crashes sometimes, prompting me to recover my documents.

Why do I believe the result is unexpected?  Should I *expect* OpenOffice to crash when saving a file?  
I'm starting to wonder these days.

More information concerning the document?  It's a 64 page workbook document utilizing many pictures 
in png, tiff, and jpeg format that makes heavy use of paragraph and heading styles.  I'm clicking save 
from a standard toolbar and standard File menu and the standard command of Cmd+S.  The file is on a 
Macintosh, and I'm saving the file to a network drive running Windows Server.  The problem also exists 
when saving from OpenOffice on Vista.

I think Rainerbielefeld meant you have provided a corrupted file (zip) which
does not help to reproduce the problem.
The zip is approx. 170 MB while unzipped 4 Mb -> something went wrong somewhere.
Please give us a new link to an unzipped file which can be openend in OOo.

My sincere apologies for a corrupt file.  Unfortunately my server doesn't serve .odt files, and I don't have 
access to the mime types.  However, I have rezipped and reuploaded the file, this time confirming that it 
successfully unzips first.

Again, the link is: http://kenpardue.com/misc/oo/ClimbingWoodenPoles.odt.zip

Tried 5 times with "Ooo 3.1.0 WIN XP multilingual version German UI activated 
[OOO310m11 (Build 9399)]"
and 5 times with "Ooo Dev 3.2.0 multilingual version English UI WIN XP:
[DEV300m49 (Build 9403)]"

Result: Hard work for my HDD, but no crash!

MAC-specific?

I've also had it crash on a Windows Vista machine.  Could it have something to do with the document 
loading over a network?

For what it's worth, we load and save MS Word documents, even documents as large or larger than this 
one, across the same network drive all day long.

A quick update to also note that the same problem happens with the following
file.  I believe this ONLY happens on OS X.  On the other systems it saves
slowly, but it saves.  It crashes on Save (Cmd+S, File->Save, and Save icon in
toolbar) and while AutoSaving.

No intention of being *impolite*, but here's a link to the full file in case
anyone would like to test it.  I have ALSO confirmed that this file crashes in
the same fashion when saved locally on a Mac, and not across a network drive. 
Can anyone confirm this on another Mac?

I have also tried to completely recreate this file by pasting the text in as
Unformatted text and then inserting all of the pictures via Insert -> Picture ->
From File using JPEG files.

A copy of the crash report will follow in a subsequent attachment.

Updated to add the link: http://kenpardue.com/misc/oo/TransformerConnections.odt.zip

Created attachment 62776 [details]
Crash Report from trying to save the file Transformer Connections.odt

Two quick updates: 

On the Transformer Connections document linked above, I have confirmed that this
also crashes in OpenOffice 3.1 on Windows Vista.  Seems like every single time
on this document.

I have tested saving the document in OpenOffice 3.0 on the Mac and it saves just
fine.  Something introduced between OpenOffice 3.0 and 3.1 seems to be the culprit.

Does that help you guys in pinpointing what the issue might be?

In the meantime, I have no choice but to return to using OpenOffice 3.0 until
this is fixed.

Can anyone confirm this?  On a Mac or otherwise?  Is this something that can be
fixed by 3.1.x or 3.2?

MRU->PL: I was only able to reproduce the crash on MacOS. Just open the document
mentioned under the link, save it -> crash.
Maybe this is the same as you already have as internal task 160224. I have sent
a crash report, I will post the ID here later.

This is certainly not mac specific; what happens is that the OOo process grows
over the 4GB limit and dies at some point because further memory allocation
fails. This certainly has to do with the file contents, but it seems to happen
rather often while creating the thumbnail image when saving. (mru's mac mini
most likely has less memory availble, so it simply fails earlier due to virtual
memory exhaustion).

When I debugged this the failed allocation was always in a bitmap; each bitmap
was large but not unreasonably so (in the 12MB area), so I can only conclude
that it is too many of them at the same time that breaks the camel's back. I
caught the failed allocation (which is a thing we should do anyway), but then it
simply crashed somewhere else for the same reason: out of memory.

pl->cd: There are some really huge VDevs involved, perhaps it would be possible
to limit the size of those when creating the thumbnail. Also I'm not sure
whether you do the thumbnail generation, or whether this is not an optimization
that would need to be done in the applications or the drawing layer. Setting aw
on CC for that.

cd->mav: Could you please have a look.

I confirm that I have been suffering this problem for many frustrating months. I have downloaded the sample file and get the same result.

It is interesting, and confusing, that using linked images instead of saving them in the file leads to exactly the same problem. Moving the file to a different folder (so that the image links are broken) allows the changes without problem. Based on my experience, it definitely has something to do with large images or maybe a large number of images.

My OS: Linux Ubuntu Lucid 10.04 64-bit
OO version: 3.3.0

I had the very same problem with OOo 3.30 on Mac OSx86. No way to work with the file in either OOo3.2.1, OOo 3.0.0 or Libreoffice. Every second to third time I tried to save it, the memory load would rise in the end to 3-5gb and then crash. I then opened it on Windows (virtual machine) where it saved slow but fine. It turned out that some of the .png files wouldn'd be displayed. Reinserting them gave a "graphic filter not found" error. Resaving these files in png "ASCII"coding instead of binary coding eventually solved the problem. After exchanging all the problematic graphics the file saved fine again on mac too. I hope that helps!

I forgot about the existence of this bug. It's been a long, long time -- since 2009, for pity's sake.

I have found a tentative solution (from the OO forums). I have not put it to a full test yet, so feedback would be great.

Go to Tools > Options > Memory.
Set Number of Steps to a low value (say, 20).
Under Graphics Cache, set 'Use for Open Office.org' to its maximum (256Mb on Linux); and 'Memory per Object' to a large value (I use 5Mb).
Set Number of Objects to a sufficiently large value (I have chosen 120).

The Memory per Object must be sufficient for the largest graphic, plus some 'spare'. The Number of Objects must be sufficient for the total number of graphics plus other objects. Look at File > Properties > Statistics.

This doesn't solve the problem of OO running like cold treacle with a large number of graphics, but it does (so far) seem to solve the problem of crashing with them.

Reset assigne to the default "issues@openoffice.apache.org".