I can confirm the crash also on Linux.

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

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...

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...

One more hint: Avoiding the parts that throw assertions makes no difference, still crashing.

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...

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.

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...

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...

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...

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(?)

Jumped over the asm code that frees the weak reference mxDocumentHandler in ~ParserData(), all works well. That reference shows to a SlideFragmentHandler, checking lifetimes...

Destruction of the last of three SlideFragmentHandler crashes; the destructor is used to actually do something, lets see...

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.

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...?

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?)

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.

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.

"alg" committed SVN revision 1571426 into trunk:
i118640 force early destruction of last FragmentHandler to not let it use an ...

Rechecked, committed, done.

Adapting flags

I can verify the fix on local build of branch AOO410, rev. 1582710

Verified on Ubuntu 10.04 (64bit) with build from branch AOO410 (rev. 1583666)