When I try to open a some presentation by libreoffice Impress 5.1.0.3, there is message std::bad_alloc. Then I have to kill soffice.bin process. when I open the presentation again LO recover that, but then LO start to crashes again and again... I think that the presentation is made in LO Impres 4 or 3.5 even (I do not know how to check this). Sorry for my english.
Maybe you could try getting a trace of the error: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information Can you share the presentation on Bugzilla? Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information/document.
Created attachment 123559 [details] Here is the file.
Reproduced. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: b89feb8018bf3610faf01e73995d576f6566e20b CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-07_03:36:17 Locale: fi-FI (fi_FI)
Seems to happen at preparing the preview for slide 6 (may be reduced to that slide, though). Crash is in SvMemoryStream::ReAllocateMemory which gets a negative value as diff. That may be allowed, but leads to a nNewSize value of 4294934350 (0xffff7f4e) which is probably too big. All this comes from reading a Metafile and there a a VersionCompat which gets created and reads in a size of 0xffff0000 which it tries to seek forward over. The action Type read is 1753 and probably not a VersionCompat, but that is of course the default at MetaAction::ReadMetaAction. Ths looks like a malformed metafile, checking the presentation file contents directly...
Only png's in the picture filder, no metafile. Reducing pages to see where the problem is...
Problem is Page8, Object 4, and there, it's replacement.
I have checked all metafiles contained (only in replacement objects) and removjhed 'Object 4', but when loading the document there is also a metafile coming up with an action '53434' which also crashes. Need to check where that file comes from...
Oh my God, I have written 20 minutes a comment and I don't see that. Oh my God. My english is so bad (I am active user of google translator :) ). But, there is a bigger problem.. I am just a ordinary user of computers and apps, not a geek :) . I love free software and that is the reason why I reported this bug (if it is). "Crash is in SvMemoryStream::ReAllocateMemory which gets a negative value as diff. That may be allowed, but leads to a nNewSize value of 4294934350 (0xffff7f4e) which is probably too big." and the other stuff is so strange for me. Anyway, thank you Buovjaga and Armin Le Grand fo yours comments. Salute to you.
@djnesic: Thanks for your comments and the task - my comments are for documenting what is going on for evtl. insights of developers following and might have a direct idea what might be the reason, also for self-documentation. No need to understand that or to react ;-)
This is really strange. The Metafile is broken, but what the current importer does is dangerous from my point of view: - The Stream is in read/write mode, it should be in read-only mode. If forcing to read-only, the too-big seek leads to seeking back to start of file, importer ends at least without crash. Is it really intended that seking beyond EOF in a read-only file resets to start of file? - When keeping read/write, the seek does not go to EOF, but tries to extend the file to the needed size. Can this be intended? It is basically *very* dangerous, can lead to crashes like this and can evetually be used to infiltrate code/pages (security?). I do not dare to change stuff in SvStream, but can at least seek to EOF when a seek beyond the file length is intended in ~VersionCompat. Trying that...
Checked deeper, the malformed mtf does as intended, seeks far beyond and goes to EOF, that causes not the crash. It is more complicated - the graphic and the contained Metafile come from an OLE object. That object seems to create a malformed metafile. Cheking
The (replacement) graphics for the OLE are fetched using EmbeddedObjectRef::GetGraphic(), that again has a bNeedUpdate switch. If forcing always to true, all looks good. Thus it looks like the file was created/written with a Office version which produced invalid metafiles for the embedded OLEs. Checking where these OLEs fetch their metafiles from initially, there are quite some Math OLEs embedded
At OLE import the added StarMath objects with their previews in metafile format get loaded. That metafiles are corrupt, thus getting a (preview-) Graphic goes wrong or crashes. Added code to detect inconsistent metafiles and stop loading them. Interestingly, in this case it is possible to try to 'repair' that state by trying to get a newly created (preview-) Graphic fro mthe OLE. Added code to do this. This allows Document self-repair in those cases. When saving once after load all is well again. Doing more checks on this.
The repaired and saved file works well at load time, that excludes that there is currently a general error in the metafile round trip as OLE preview/replacement.
Looks good, added change to gerrit for review.
BTW: Another workaround is to remove 'ObjectReplacements' from the ODF archive, this also re-creates the graphics at load-time.
After updating I see that with commit c5bee7b8c1055e5052a261c8755bdb150fb27494 a task was fixed (also see tdf#98600 and tdf#98622) that is related to this. Checked, all works well. This task is also related to that stuff. *** This bug has been marked as a duplicate of bug 98620 ***
Think Armin intended this to be duped to bug 98622 for Noel G's work on Math OLE metafile parsing, rather than 98620 *** This bug has been marked as a duplicate of bug 98622 ***
Removed submit from gerrit, no longer needed
@ V Stuart Foote: Ves, indeed. Thanks for correcting this!