Bug 98136 - std::bad_alloc in LO IMpress
Summary: std::bad_alloc in LO IMpress
Status: RESOLVED DUPLICATE of bug 98622
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: high major
Assignee: Armin Le Grand
Depends on:
Reported: 2016-02-24 13:02 UTC by djnesic
Modified: 2016-03-18 14:12 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Here is the file. (261.43 KB, application/vnd.oasis.opendocument.presentation)
2016-03-14 13:33 UTC, djnesic

Note You need to log in before you can comment on or make changes to this bug.
Description djnesic 2016-02-24 13:02:57 UTC
When I try to open a some presentation  by libreoffice Impress, 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.
Comment 1 Buovjaga 2016-03-14 12:49:40 UTC
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?

Change back to UNCONFIRMED after you have provided the information/document.
Comment 2 djnesic 2016-03-14 13:33:16 UTC
Created attachment 123559 [details]
Here is the file.
Comment 3 Buovjaga 2016-03-14 13:41:17 UTC

Win 7 Pro 64-bit Version:
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)
Comment 4 Armin Le Grand 2016-03-16 15:58:21 UTC
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...
Comment 5 Armin Le Grand 2016-03-16 16:06:40 UTC
Only png's in the picture filder, no metafile. Reducing pages to see where the problem is...
Comment 6 Armin Le Grand 2016-03-16 16:37:40 UTC
Problem is Page8, Object 4, and there, it's replacement.
Comment 7 Armin Le Grand 2016-03-16 17:01:49 UTC
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...
Comment 8 djnesic 2016-03-16 17:20:29 UTC
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.
Comment 9 Armin Le Grand 2016-03-17 08:18:33 UTC
@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 ;-)
Comment 10 Armin Le Grand 2016-03-17 09:35:20 UTC
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...
Comment 11 Armin Le Grand 2016-03-17 10:31:24 UTC
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
Comment 12 Armin Le Grand 2016-03-17 11:00:27 UTC
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
Comment 13 Armin Le Grand 2016-03-17 12:17:34 UTC
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.
Comment 14 Armin Le Grand 2016-03-17 12:24:31 UTC
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.
Comment 15 Armin Le Grand 2016-03-17 13:02:55 UTC
Looks good, added change to gerrit for review.
Comment 16 Armin Le Grand 2016-03-17 13:08:09 UTC
BTW: Another workaround is to remove 'ObjectReplacements' from the ODF archive, this also re-creates the graphics at load-time.
Comment 17 Armin Le Grand 2016-03-17 17:19:30 UTC
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 ***
Comment 18 V Stuart Foote 2016-03-17 17:44:28 UTC
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 ***
Comment 19 Armin Le Grand 2016-03-17 19:40:48 UTC
Removed submit from gerrit, no longer needed
Comment 20 Armin Le Grand 2016-03-18 14:12:02 UTC
@ V Stuart Foote: Ves, indeed. Thanks for correcting this!