Issue 103888 - WW8: crash (in graphics memory allocation) saving a huge document or scrolling to graphic
Summary: WW8: crash (in graphics memory allocation) saving a huge document or scrollin...
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: open-import (show other issues)
Version: OOo 3.1
Hardware: PC All
: P2 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: crash
Depends on:
Blocks:
 
Reported: 2009-07-30 00:22 UTC by vvucic
Modified: 2017-05-20 11:13 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description vvucic 2009-07-30 00:22:31 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
Comment 1 eric.savary 2009-07-30 00:43:09 UTC
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.
Comment 2 michael.ruess 2009-07-30 10:52:48 UTC
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?
Comment 3 Mathias_Bauer 2009-07-30 14:28:25 UTC
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.
Comment 4 vvucic 2009-07-30 19:39:38 UTC
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
Comment 5 michael.ruess 2009-09-21 15:10:18 UTC
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.
Comment 6 michael.ruess 2009-09-22 08:41:21 UTC
Report ID's are rp7djdc and r27djdc.
Comment 7 sven.jacobi 2009-12-17 10:37:52 UTC
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.
Comment 8 sven.jacobi 2010-09-27 15:29:32 UTC
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.
Comment 9 Oliver-Rainer Wittmann 2010-09-28 11:33:24 UTC
This crash and the corresponding "bad" memory allocation already occurs at least
since OOo 3.0
--> adjusting target
Comment 10 Marcus 2017-05-20 11:13:12 UTC
Reset assigne to the default "issues@openoffice.apache.org".