Issue 105275 - Crash on loading MS PowerPoint file
Summary: Crash on loading MS PowerPoint file
Alias: None
Product: Impress
Classification: Application
Component: open-import (show other issues)
Version: DEV300m58
Hardware: Mac Mac OS X, all
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: sven.jacobi
QA Contact: issues@graphics
Depends on:
Blocks: 99999
  Show dependency tree
Reported: 2009-09-22 15:19 UTC by
Modified: 2011-03-31 12:00 UTC (History)
5 users (show)

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

mapped stack (4.11 KB, text/plain)
2009-09-25 15:27 UTC,
no flags Details
problematic PPT-export result (from OSX 10.4) (231.50 KB, application/
2009-09-25 15:36 UTC,
no flags Details
corresponding PPT-export result from OSX 10.5 (231.50 KB, application/
2009-09-25 15:44 UTC,
no flags Details
another mapped stack (6.00 KB, text/plain)
2009-09-25 16:13 UTC,
no flags Details
odp file not crashing (169.41 KB, application/vnd.oasis.opendocument.presentation)
2009-10-15 19:56 UTC, sven.jacobi
no flags Details
odp file crashing (171.14 KB, application/vnd.oasis.opendocument.presentation)
2009-10-15 19:56 UTC, sven.jacobi
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description 2009-09-22 15:19:16 UTC
See internal crashreport: 101682949

On MacOS X 10.4 since DEV300m58;
Autotest: testautomation/graphics/required/i_updt_2.bas tiFileSaveAs()

Manual reproduction:
- Load file: testautomation/graphics/required/input/tbo_alf_.odp
- Save as MS PowerPoint 97/2000/XP file: x.ppt (or as template x.pot)
- Load the file x.ppt
- Bum!
Comment 1 ooo 2009-09-23 09:11:27 UTC
KA=>HDU: could you take a first look, please, and involve SJ if necessary?
Comment 2 2009-09-23 09:36:27 UTC
Since the internal tooling doesn't have a search field for reportnos reverse engineering was needed to the 
find the matching reportid rds85dc. A stackid has not been created yet and it also cannot be created yet 
manually. Probably because the stackcount is still too low.
Comment 3 2009-09-23 13:53:17 UTC
Not reproducable on OSX10.5, interesting.
Comment 4 2009-09-25 15:27:19 UTC
Created attachment 64970 [details]
mapped stack
Comment 5 2009-09-25 15:36:52 UTC
Created attachment 64971 [details]
problematic PPT-export result (from OSX 10.4)
Comment 6 2009-09-25 15:44:08 UTC
Created attachment 64972 [details]
corresponding PPT-export result from OSX 10.5
Comment 7 2009-09-25 15:55:38 UTC
With OSX10.4 it was possible to reproduce the problem using either of the two attached PPT-export 
results (one from OSX10.4, the other from OSX 10.5) attached. Tested with DEV300_m59.

@sj: unfortunately the crash reporting infrastructure in OOo didn't manage to sent a good stack. Use the 
mapped_stack I attached above (from the OSX builtin subsystem) instead. Good luck!
Comment 8 2009-09-25 16:13:54 UTC
Created attachment 64973 [details]
another mapped stack
Comment 9 sven.jacobi 2009-10-15 19:56:20 UTC
Created attachment 65391 [details]
odp file not crashing
Comment 10 sven.jacobi 2009-10-15 19:56:57 UTC
Created attachment 65392 [details]
odp file crashing
Comment 11 sven.jacobi 2009-10-15 20:08:37 UTC
The animated gifs/png graphics within the document are not the reason for this

105275a.odp is the original presentation -> not crashing.
105275b.odp is the presentation after saving to ppt / reloading / saving to odp
and replacing graphics with the original

(I replaced the graphics, because animated gifs can only be saved to ppt as
private png chunk, so I restored the orignal graphic to verify that we do not
have a problem with gif/png handling)
Comment 12 sven.jacobi 2009-10-15 22:23:21 UTC
With the patch from issue 102797 polygons are created which are causing this
crash, that patch is also responsible for issue 105768. By removing the
problematic code part (which is also the bugfix for i105767) this issue could be
Comment 13 thb 2009-10-16 09:36:50 UTC
@sj: those polygons are perfectly valid, and can be contained literally in
perfectly valid odf/emf/svm documents - also, the attached stack traces crash in
either drawing layer or CG's DrawRect, so there may be more behind this? Or, if
OSX can't cope, needs to be filtered at vcl's sal layer?
Comment 14 2009-10-19 11:38:52 UTC
Looks ok in CWS impress178 on Mac OS X 10.4 Intel - verified