Issue 118640

Summary: Opening the presentation document causes OpenOffice 3.3 on Windows or Solaris to crash
Product: Impress Reporter: stream
Component: open-importAssignee: Armin Le Grand <Armin.Le.Grand>
Status: CLOSED FIXED QA Contact:
Severity: Major    
Priority: P3 CC: Armin.Le.Grand, issues
Version: OOo 3.3Keywords: crash, ms_interoperability
Target Milestone: 4.1.0   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Secondary School Maths Presentation none

Description stream 2011-11-25 20:37:54 UTC
Created attachment 77046 [details]
Secondary School Maths Presentation

My daughter brought home a maths homework powerpoint presentation which caused OpenOffice Impress 330m20 to crash on both Windows XP and OpenIndiana b151a.
However when I booted the Windows XP into Linux which had OpenOffice 3.2 installed it was capable of opening the document
Comment 1 Marcus 2011-11-25 22:31:41 UTC
I can confirm the crash also on Linux.
Comment 2 Armin Le Grand 2014-02-21 01:21:19 UTC
Can confirm on win7. Got the following asserts:

Error: PropertySet::implSetPropertyValue - cannot set property "NumberingLevel" From File C:/aoo/svn_trunk47/main/oox/source/helper/propertyset.cxx at Line 171
Error: PropertySet::implSetPropertyValue - cannot set property "CharCaseMap" From File C:/aoo/svn_trunk47/main/oox/source/helper/propertyset.cxx at Line 171
Error: PropertySet::implSetPropertyValue - cannot set property "IsNumbering" From File C:/aoo/svn_trunk47/main/oox/source/helper/propertyset.cxx at Line 171
Comment 3 Armin Le Grand 2014-02-21 01:51:14 UTC
Indeed NumberingLevel is member of SVX_UNOEDIT_OUTLINER_PROPERTIES (both in editeng), but not member of SVX_UNOEDIT_NUMBERING_PROPERTIE which is used in sd to define a SvxItemPropertySet whcih is accessed in GetStylePropertySet() and thus used for UNO API style access, so in SdStyleSheet::setPropertyValue an UnknownPropertyException is thrown. But this is not the reason for the crash, these are catched. Need sfx2, svl with debug...
Comment 4 Armin Le Grand 2014-02-21 20:11:51 UTC
Cannot really nail it, its somewhere around parsing the master page contained, my closest breakpoint is at objstor.cxx lin 738, where it does not come back but somehow uses corrupted mem or an exception exit...
Comment 5 Armin Le Grand 2014-02-21 20:16:23 UTC
One more hint: Avoiding the parts that throw assertions makes no difference, still crashing.
Comment 6 Armin Le Grand 2014-02-21 20:26:04 UTC
In SfxObjectShell::ImportFrom at the end standing on the return statement does not get back to SfxObjectShell::DoLoad which is on the stack, but crashes. Might be the cleanup of one of the local objects...
Comment 7 Armin Le Grand 2014-02-21 20:39:56 UTC
The XFilter release seems to crash; In the WeakImplHelper5 the release() has a cppu::OWeakObject {m_refCount=1 m_pWeakConnectionPoint=0x00000000 m_pReserved=0x77777777 }, I am not sure if m_pReserved is used and if that value is good. One quick test shows that jumping over the XFilter release (in assembly mode) makes the document load well.
Comment 8 Armin Le Grand 2014-02-21 22:08:04 UTC
What goes wrong is the destruction of the PowerPointImport implementation object, more precise the oox::core::XmlFilterBase from which it is derived. There in XmlFilterBaseImpl it's the member FastParser. XmlFilterBaseImpl has an implicit destructor, need to follow all this in assembly...
Comment 9 Armin Le Grand 2014-02-22 00:48:29 UTC
The ~FastSaxParser() in sax fails in destruction of his member ParserData, that is a struct holding uno references, a locale and has con/destructor. It also has an inmplicit copy construtor used in FastSaxParser::pushEntity when it gets pushed to a ::std::stack< Entity > in FastSaxParser::parseStream. The origilally local Entity incarnation in the same method explicitely uses XML_ParserFree( entity.mpParser ) what the destructor of the copy-constructed Entity incarnation does not do.
Also checked where 'XML_ParserFree' comes from, it seems to be a macro in Python (thus may also be python-version related). I am no expert in this area.
My guess is that class FastSaxParser should not use a ::std::stack< Entity > which implicitely copy-constructs Entity-incarnations and destroys them, but better should use a ::std::stack< Entity& > type. Lets try that...
Comment 10 Armin Le Grand 2014-02-22 01:26:21 UTC
There is one Entity instance left after parsing the file, so there must be a case where inside FastSaxParser::parseStream not the needed pair of calls to pushEntity/popEntity is done; this can only happen when an exception of so far unknown type is thrown, that may have to do with the exceptions triggered by the asserted non-working attribute changes. Adding another catch case and checking...
Comment 11 Armin Le Grand 2014-02-22 01:57:01 UTC
Was also a false trace; its definitely the destruction of the local member maData of FastSaxParser, there it seems to be the mxDocumentHandler. That incarnation of the parser was used to load Fragments, these may have set mxDocumentHandler to something that is no longer there(?)
Comment 12 Armin Le Grand 2014-02-22 02:20:10 UTC
Jumped over the asm code that frees the weak reference mxDocumentHandler in ~ParserData(), all works well. That reference shows to a SlideFragmentHandler, checking lifetimes...
Comment 13 Armin Le Grand 2014-02-22 02:24:57 UTC
Destruction of the last of three SlideFragmentHandler crashes; the destructor is used to actually do something, lets see...
Comment 14 Armin Le Grand 2014-02-22 02:34:33 UTC
The problem is with the 1st of three SlideFragmentHandler, it inserts four shapes, problem is the first. It uses the GraphicPath "ppt/media/image1.wmf" and has the name "DefaultOcx" and is a FormControl. It crashes on construction of AxControlFragment in ComplexShape::implConvertAndInsert.
Comment 15 Armin Le Grand 2014-02-22 02:48:39 UTC
Inn XmlFilterBase::importRelations it tries to use mxImpl->maRelationsMap in xmlfilterbase.cxx in oox which is a 'typedef RefMap< OUString, Relations > RelationsMap' where RefMap is an own template class in oox/helper/refmap.hxx, the operator[] on the empty maRelationsMap crashes.
Interestingly the definition does not have an operator[] directly but is derived of type ::std::map which has one.
maRelationsMap gets never filled, thus it must always have been empty. Maybe the change to the standard STL makes this operator crash now...?
Comment 16 Armin Le Grand 2014-02-24 16:22:35 UTC
Has nothing to do with STL, the buffer accessed is already destroyed. That again happens due to the mechanism used to import the stuff: For every part to be imported a FragmentHandler derivate (as needed for the context) is created and set at the parser. This triggers the deletion of the previous FragmentHandler which will create imported elements in its destructor.
At the end of import the parser is destroyed and that will execute the last FragmentHandler destructor which will create imported objects. That last FragmentHandler is the form control importer which is normally empty and does nothing, thus will not stumble over the already destroyed buffer maRelationsMap. In the bugdoc this is different; there is content for this and it will try to use the already destroyed maRelationsMap.
Thus this should happen with all pptx containing FormControls, trying to create one as example (how to iinsert a form control to ms ppt2010?)
Comment 17 Armin Le Grand 2014-02-24 16:24:46 UTC
Possible fix: Add a mxImpl->maFastParser.setDocumentHandler(0) to XmlFilterBase::~XmlFilterBase() to force the execution of the destructor and thus object creation of the last FragmentHandler before XmlFilterBase::mxImpl gets destroyed which is holding the needed context data. Checked, that works well.
Comment 18 Armin Le Grand 2014-02-24 16:40:43 UTC
Created a new pptx with MSPPT2010 with one form control and the same crash happens; this proves the theory, so I can apply the intended fix. Preparing and re-cheching again...
BTW: The newly created pptx throws the same exceptions as mentioned in comment 2.
Comment 19 SVN Robot 2014-02-24 20:25:27 UTC
"alg" committed SVN revision 1571426 into trunk:
i118640 force early destruction of last FragmentHandler to not let it use an ...
Comment 20 Armin Le Grand 2014-02-24 20:25:44 UTC
Rechecked, committed, done.
Comment 21 Armin Le Grand 2014-02-24 20:25:58 UTC
Adapting flags
Comment 22 Oliver-Rainer Wittmann 2014-04-01 08:18:51 UTC
I can verify the fix on local build of branch AOO410, rev. 1582710
Comment 23 Oliver-Rainer Wittmann 2014-04-02 11:08:49 UTC
Verified on Ubuntu 10.04 (64bit) with build from branch AOO410 (rev. 1583666)