Apache OpenOffice (AOO) Bugzilla – Issue 103888
WW8: crash (in graphics memory allocation) saving a huge document or scrolling to graphic
Last modified: 2017-05-20 11:13:12 UTC
WHen I want to open file that is 101 Mb of size it crashes. If I Succeed to open it it crashes when I want to save it. This is output when I Start openoffice from terminal: http://pastebin.ca/1511604 I use opensuse 11.0 and the same happens when I use openoffice that came with opensuse and openoffice that is installed fom openoffice.org THanks, veki
Remarks, comments, questions: 1. I see "/opt/openoffice.org3/" in your crash report. Are you using 3.0, 3.0.1 or 3.1? Please test this again in 3.1 or DEV build. 2. Please upload the document on a ftp server and post the link here. 3. Remark: 101Mb is very, very, very... but very, very BIG for a text document... I hope you realize it and that your are probably testing the limits of OOo... so our "enthousiasm" about fixing it won't be that much... ;) Meaning: such cases don't happen everyday so it lowers the priority. 4. Please send the crash report so that we can find it and analyze it in our database.
MRU->HB / MBA: the stack which can be seen under the link lists the msword lib in the lower part. But it does not look like that the crash happens in the filter. Is the stack of worth for you?
The stack lets me think that this is a problem in a graphic filter. The ExportGraphic call crashes in SvMemoryStream::AllocateMemory called from SvMemoryStream::Write. The reason can be either a memory shortage or a useless allocation caused by a wrong stream size. Sven probably knows a lot of examples like that. I assume that without having the document for testing we can't do anything here, but maybe Sven has another opinion.
The same file is easily openned and saved by MS Word 2003, it is openned easily with IBM Lotus Symphony and crashes during the save process with IBM Lotus Symphony. Besides all arguments this should not happen. I uploaded file on the following address: http://www.gnulinuxcentar.org/doktorat-milena.doc.tar.gz Best wishes, Vedran Vucic
Confirmed this on Windows. MRU->SJ: the crash does not happen in the filter directly and not only when exporting. It also happens when one tries to jump to a graphic via navigator or scrolling down to the first one.
Report ID's are rp7djdc and r27djdc.
I can't download the file, it is only having 4,4k if I am trying this. @MRU maybe you can provide this bugdoc to me.
sj->od: If loading the document, the memory footprint is much too high > 1,2gb. I think this is because no graphic is swapped out. I had the same problem with the minimizer in issue 114741, there I got a 400mb presentation (containing unmodified camera photos). After loading the document in Impress, the StarOffice memory footprint was by about 120mb... everything was fine so long. If now the minimizer was started, a GraphicID from each graphic was acquired (via API)... this leads to the problem that each graphic was swapped in... having now a memory footprint of > 1,6gb. In my case this also leads to missing graphics. I fixed this by swapping out each graphic after acquiring the GraphicID so the memory footprint was stable - now the document size doesn't matter.
This crash and the corresponding "bad" memory allocation already occurs at least since OOo 3.0 --> adjusting target
Reset assigne to the default "issues@openoffice.apache.org".