i'm trying to load the cisco icons set available here: <http://www.cisco.com/web/about/ac50/ac47/2.html> (ppt format, in the section "Icons for PowerPoint"). But when Impress loads it, my process grows fastly (1.7GB) and swapping occurs. For information, the original size of the ppt file is about 8 megas.
LO 3.6 beta 2 crashed on this file with a msg to console: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc 3.5.3.2 took some time but opened it, hence 'regression'. The file embeds 417 wmf/emf images.
Ok, not a regression. I was able to load it in 3.6b2 after killing some apps.
I can confirm problems with WIN, but several aspects are very different, so I submitted additional "Bug 52631 - CRASH when FILEOPEN particular .ppt" @Valek: You tested with Linux? And if yes with what one? <http://wiki.documentfoundation.org/BugReport_Details#Version>! You changed Version by mistake? @Kartoch: Exact Linux Version?
I meet the same problem, but with the MS Windows version only. Using Windows version of LibreOffice 3.5.5.3: It crash (at about 60% progress of loading the file). Using FreeBSD version of LibreOffice 3.5.5.3: It works (with a pause a about 60% progress of loading the file). Using MacOSx version of LibreOffice 3.5.5.3: Like FreeBSD, it works (with a pause a about 60% progress of loading the file). Regards,
(In reply to comment #3) > I can confirm problems with WIN, but several aspects are very different, so I > submitted additional "Bug 52631 - CRASH when FILEOPEN particular .ppt" Rainer, I guess it crashes only if runs out of memory. So if it doesn't for you, try to load some memory eaters. > @Valek: > You tested with Linux? And if yes with what one? Yes, Ubuntu 12.04 > <http://wiki.documentfoundation.org/BugReport_Details#Version>! You changed > Version by mistake? I didn't revert it back by mistake after I found that it's not a crash on 3.6.b2. Sorry about it.
Created attachment 64924 [details] screenshot of bad EMF In this case PPT is a kind of 'wrapper' for 420 pictures (249 WMFs, 169 EMFs and 2 JPEGs). I believe I know what's wrong with this file. The whole file is ~8.4Mb. Picture #320 is a OfficeArtBlipEMF of ~6Mb. Decompressed #320 is ~530Mb (five hundred thirty megabytes). I dumped it from PPT and opened in LO Draw. Screenshot is attached. An EMF image like this could be fitted in 530 Bytes, the one in question wastes space to store enormous number of control records, which could be skipped without impact for the end result. Nothing interesting in its EMF part. Hence I guess someone need to find which function call from "open file" through "handle RT_Slide" to "handle EMF record" doesn't survive "insufficient memory" exception. I'm not a user interaction expert, but probably some additional (other than progress bar) hints could be provided to users in such situation. Also if LibreOffice decompress the whole BLIP and parse it, then probably that part can be changed to take decompression in blocks (afaik supported by zlib) and discard parsed parts. That could introduce little to no delay for handling, but will definitely reduce amount of memory required and improve overall responsiveness of the system. P.S. I had contacts of the Cisco ppl responsible for those files. I will try to contact them and ask to eliminate the problem within this PPT file.
Rodo, any chance to do the decompression by blocks?
I put fdo#52631 as see also. I don't reproduce crash (as indicated in fdo#52631) and don't have excessive memory consumption with master sources or 3.6 sources (both updated today with a brand new LO profile).
Oups, should have give a link and title: https://bugs.freedesktop.org/show_bug.cgi?id=52631 CRASH when FILEOPEN particular .ppt
I close this bug report as RESOLVED WORKFORME because it is no longer reproducible. Tested again on: - Libreoffice 4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 - Libreoffice 4.2.1.1 Build ID: d7dbbd7842e6a58b0f521599204e827654e1fb8b - Libreoffice 4.3.0.0.alpha0 ID: 95700a2d7d09893fe16aadb406e93bf7164f7422 Feel free to open this bug report again if you find that the bug is still reproducible under some special circumstances, etc.