Reassign issue to owner of selected subcomponent

Reassigned to Christian.

I can't reproduce the bug because I don't have such big files. Please
send me such a file as attachment.

I created a document with nearly 80 MB (78MB) by my own. loading the
document takes much time but I don't get a crash. Please send me your
document to reproduce the bug. 

A testcase is located at http://www.ballsome.com/testcase.rar

I try several times to download your testfile but I don't get a file
that winrar can read.

Ok, I re-zipped, re-uploaded, and tested it out myself. This one
worked for me, although be warned that it took a good 5-10 minutes to
unzip the thing. The file is: http://www.ballsome.com/files/testcase.zip

Can you tell me when you've gotten this file? It's eating up too much 
space on my server....

I got the document and could unzip it. Thanks for the doc. 

I can reproduce the doc in the OpenOffice.org 1.0 version. It seems to
be ok in the latest internal version. 

Hi,

I examined the presentation and found the problem.

There are eight Excel ole objects embedded which are
converted to Calc ole by default. That is the reason 
that the import takes so much time, it is comparable 
to the time that is needed to import one PowerPoint 
document and eight Excel documents and of course
the memory consumption is equivalent.

The good news is that you can switch off the feature
which converts ole objects into the own format under
Tools/Options/LoadSave/Microsoft Office/ .
If you uncheck all these checkboxes, the import 
of the PowerPoint document should make it in adequate
time. 

Because this feature is making so to much trouble I
changed the default, and hope that the change will make
it into the next Stable OO build. 

The fix takes place in:
officecfg/data/org/openoffice/office/Common.xcd -r1.83

I hope I could help,
Sven

Tried to open a rather large MS-Word .doc file. (1063 pages around 
7MB size)

OpenOffice tries to open it but freezes after a while. You can easily 
see it with an ps -Al statement - the first soffice.bin just stops 
progressing (in my case around 2:02) I tried to change options/memory 
setting to no avail.

Only kill -9 helps.

Conrad

Tried to start OO again from the Linux shell command line. The last 
thing OO says before crashing ist:
SIOCGIFADDR got '00:00:00:00:00:00'    

Conrad

Christian: This seems to be about a .ppt file, not .doc -> yours.

Conrad: You can't "hop on" this issue with your problem only because
this is about MS Office filters, sorry. Problems with another file
always means you have to file another issue. Plus: In your case it is
MS Word. This task here had a wrong title, but as the first sentence
in the description and Sven's statement show, it is about
Presentations. I changed the title to meet the facts now. FYI: You
can't submit and attach at the same time. After submitting an issue,
you have to access it again before being able to click "Create a new
attachment".

ALL: Have one statement about file sizes. The past has shown that in
most cases it is possible to reduce a file to a few pages while still
showing the problem. There are very few problems that need the "full
size" docs.

To reduce a MS documents in size, do as follows: 

Disable "fast save" as it tends to pump up the docs' sizes: In MS Word
via menu: Tools-Options-Save, there is a checkbox "enable fast save".

Then you sometimes can witness "a miracle" in file size by re-saving
the doc once. If this is not enough, go on like this:

1. Open Bugdoc in MS Office
2. delete second half
3. Save (new name)
4. Open Bugdoc again
5. Delete first half
6. Save (new name)
7. Load both in OO
8. Take the doc that still shows the problem and repeat from 1. until
you can't reproduce it in either half or you think it's small enough
to send it.

I remember no case in the past when _simple document size_ was the
source of a problem. Size only makes your machine swap and a file
server run out of memory. Therefore it is always useful to give it a
try the way I described.

I can load the doc the first time. When I reload the doc (Files/Relod)
I get a crash.
When I try to load it with the latest internal versionI get a 'Error
loading document ..... incorrect file format.'

It's all a problem of memory. I tested it, having enough memory it is 
possible to load and also reload this document. And it can't be fixed 
that a document is crashing here and there if there is too less 
memory available. Even Microsoft PowerPoint is having problems if you 
try to edit one of these ole objects and copy paste them into another 
application.

I think this Issue should be closed.

I had 384 mb of RAM when I came upon this problem. That should be more
than enough memory.

At the URL http://www.cpt.dur.ac.uk/~levell/bigppt.zip is a 28meg
PowerPoint file (zipped). It opens fine on even relatively low-specced
WinTel machines running MS PowerPoint but if I load it into
OpenOffice, even with little else running it exhausts all the memory,
then the swap space and then exits. My machine has 3/4 of a gig of
ram, more than a gig of swap so it should manage (Tried 1.0.2 but not
latest CVS) and am running RH7.3

Reassign owner.

With some further investigation, it really does seem just a massive
memory use issue - if I split the ppt file up in powerpoint into two
smaller files I can import both into OpenOffice (albeit with a lot of
activity in swap). Once the whole file is imported memory use drops
right down to something normal - it seems like it requires massive
amounts of memory for the conversion but not much for the converted
slide. 

So okay I haven't looked at the source and have no idea what I'm
talking about so feel free to tell me that but wouldn't it be possible
to "import" one slide at a time and only have roughly the memory use
of the   converted slides + a large chunk for the slide undergoing
conversion?

Changing QA contact from sw to graphics.

I come to the conclusion that the problem with the file "testcase" is
no bug, instead the file bigppt from jon is a bug and should be fixed
as soon as possible.

SJ->MSC: Would you please set the target milestone to OOo 1.1 RC,
since loading the file bigppt is mostly leading to a gpf.

change target as SJ request

SJ: This bug has been fixed now. Loading the document bigppt should
now be possible.

Bugfix was reviewed by THB, he told me that the fix looks good.

SJ->CGU: This bug is now ready to be verified in cws[draw18]

set to fixed

CGU: Verified in cws draw18 on Lin, Win. There is no version for Sols.

.

integrated in the latest internal version on Sols, Lin, Win.
I close the issue.
Please reopen the issue if you can still reproduce the bug in the OOo1.1RC

I'd like to reopen this but but do not have the requisite permissions.
With OOo1.1RC it still cannot load the file - it exhausts physical
memory (1GB) then swap (1GB) then (eventually) puts up an
"unrecoverable alert" message box and exits.

Thanks for taking the time to look into this, did the patch land in
time for 1.1RC? I'm sorry it has taken me so long to respond, I've
been away from the keyboard for a while.