Apache OpenOffice (AOO) Bugzilla – Issue 127783
Crash when opening any PPT file
Last modified: 2024-02-04 00:50:45 UTC
Created attachment 86428 [details] Sample PPT file for testing but crash occurs with any PPT All PPT files crash AOO 4.2.0 on opening on my Windows 7 x64 machine (tested with Rev. 1831525 from mseidel and also with Rev. 1832057 from the Buildbot) There is no problem with ODP or PPTX. This is a confirmed (by mseidel) regression from 4.1.5
Confirmed with every PPT I tried. Even if you save an ODP as PPT and then try to open it AOO crashes. This seems to be Windows only.
Further details: if another file has already been open (e.g. an ODS file) even if it is closed before opening a PPT file then AOO will not crash. The crash occurs if AOO is open without any file been previously opened or when AOO is closed (open by file association)
Crash still occurs every time under Windows 7 x64 with Matthias' build AOO420m2(Build:9821) - Rev. d08390903b 2019-10-22 20:51 - CYGWIN_NT-10.0 x86_64 - Development Test Build
I have tried today with my Linux build based on trunk and it did work. Is it a Windows only Issue or is it specific to 4.2.0 and Trunk it works? I will check if I can do a windows build in the next days. (Sidenote: When opening a ppt, I get tons of Assertion errors.)
I am pretty sure that this is Windows only, And it is a regression, so trunk and 4.2.0 are broken.
The sample document crashes for me on FreeBSD as well. Top 21 stack frames: ---snip--- #0 ContentAttribs::GetStyleSheet() const (this=0x8) at source/editeng/editdoc.hxx:192 #1 0x000000080448453d in ImpEditEngine::SetStyleSheet(unsigned int, SfxStyleSheet*) (this=0x80aef1710, nPara=<optimized out>, pStyle=0x80ab74380) at source/editeng/impedit5.cxx:78 #2 0x000000080447a16c in ImpEditEngine::InsertBinTextObject(BinTextObject&, EditPaM) (this=this@entry=0x80aef1710, rTextObject=..., aPaM=...) at source/editeng/impedit4.cxx:1347 #3 0x0000000804476b74 in ImpEditEngine::InsertText(EditTextObject const&, EditSelection) (this=this@entry=0x80aef1710, rTextObject=..., aSel=...) at source/editeng/impedit4.cxx:1230 #4 0x0000000804479963 in ImpEditEngine::SetText(EditTextObject const&) (this=0x80aef1710, rTextObject=...) at source/editeng/impedit4.cxx:1214 #5 0x000000080442b979 in EditEngine::SetText(EditTextObject const&) (this=0x80aea9450, rTextObject=...) at source/editeng/editeng.cxx:1383 #6 0x00000008044d322a in Outliner::SetText(OutlinerParaObject const&) (this=0x80ab64290, rPObj=...) at source/outliner/outliner.cxx:646 #7 0x0000000803b47bb5 in SdrTextObj::AdjustTextFrameWidthAndHeight(Rectangle&, int, int) const (this=0x80d98c350, rR=..., bHgt=<optimized out>, bWdt=<optimized out>) at source/svdraw/svdotxat.cxx:148 #8 0x0000000803b47eb8 in SdrTextObj::NbcAdjustTextFrameWidthAndHeight(int, int) (this=0x8, bHgt=16017840, bWdt=16684368) at source/svdraw/svdotxat.cxx:211 #9 0x0000000803b3bb84 in SdrTextObj::NbcSetOutlinerParaObjectForText(OutlinerParaObject*, SdrText*) (this=0x80d98c350, pTextObject=<optimized out>, pText=0x80d97b910) at source/svdraw/svdotext.cxx:1505 #10 0x0000000803b045b4 in SdrObject::SetOutlinerParaObject(OutlinerParaObject*) (this=0x80d98c350, pTextObject=0x80d942610) at source/svdraw/svdobj.cxx:1781 #11 0x000000080e6d2caa in SdPage::SetObjText(SdrTextObj*, SdrOutliner*, PresObjKind, String const&) (this=this@entry=0x80aeac010, pObj=0x8, pObj@entry=0x80d98c350, pOutliner=pOutliner@entry=0x80a138710, eObjKind=<optimized out>, rString=...) at source/core/sdpage.cxx:2502 #12 0x000000080e6d1a1f in SdPage::CreatePresObj(PresObjKind, unsigned char, Rectangle const&, unsigned char) (this=this@entry=0x80aeac010, eObjKind=16684368, eObjKind@entry=PRESOBJ_NOTES, bVertical=bVertical@entry=0 '\000', rRect=<optimized out>) at source/core/sdpage.cxx:466 #13 0x000000080e6d6e93 in SdPage::InsertAutoLayoutShape(SdrObject*, PresObjKind, bool, Rectangle, bool) (this=this@entry=0x80aeac010, pObj=0x0, eObjKind=eObjKind@entry=PRESOBJ_NOTES, bVertical=false, aRect=..., bInit=true) at source/core/sdpage.cxx:2226 #14 0x000000080e6d36fc in SdPage::SetAutoLayout(AutoLayout, unsigned char, unsigned char) (this=0x8, eLayout=<optimized out>, bInit=1 '\001', bCreate=<optimized out>) at source/core/sdpage.cxx:1575 #15 0x000000080e1561f1 in ImplSdPPTImport::Import() (this=0x80d867010) at source/filter/ppt/pptin.cxx:1033 #16 0x000000080e153d57 in SdPPTImport::Import() (this=this@entry=0x80d860850) at source/filter/ppt/pptin.cxx:164 #17 0x000000080e15b35b in ImportPPT(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>*, SdDrawDocument*, SvStream&, SotStorage&, SfxMedium&) (rConfigPath=..., pConfigData=pConfigData@entry=0x7fffffff9450, pDocument=pDocument@entry=0x80a144c10, rDocStream=..., rStorage=..., rMedium=...) at source/filter/ppt/pptin.cxx:2789 #18 0x000000080e740bc1 in SdPPTFilter::Import() (this=0x7fffffff94a0) at source/filter/sdpptwrp.cxx:116 #19 0x000000080e68932b in sd::DrawDocShell::ConvertFrom(SfxMedium&) (this=0x80a0b0670, rMedium=...) at source/ui/docshell/docshel4.cxx:488 #20 0x000000080141ab89 in SfxObjectShell::DoLoad(SfxMedium*) (this=0x80a0b0670, pMed=0x80aecfe10) at source/doc/objstor.cxx:753 ---snip--- In frame #0 we have this=0x8, which is definitely wrong, objects are never that low in memory. It came from frame #1, line 77: 74 void ImpEditEngine::SetStyleSheet( sal_uInt16 nPara, SfxStyleSheet* pStyle ) 75 { 76 DBG_ASSERT( GetStyleSheetPool() || !pStyle, "SetStyleSheet: No StyleSheetPool registered!" ); 77 ContentNode* pNode = aEditDoc.SaveGetObject( nPara ); 78 SfxStyleSheet* pCurStyle = pNode->GetStyleSheet(); (gdb) print pNode $2 = (ContentNode *) 0x0 So in line 78 we're calling GetStyleSheet() on a NULL pNode. The reason NULL becomes 8 is probably a second vtable pointer on an object using multiple inheritance. But "git blame" shows that whole function is unchanged since the code was initially imported in 2011. It wasn't a case of a NULL check being removed. The root cause must be elsewhere.
Please note we have a "ppt" branch that must be merged to trunk, whose purpose is to assess certain problems with PPT import. It does not solve this bug on Windows, unfortunately. But it may be worth integrating it before proceeding any further. I plan to merge the ppt branch as soon as I have time, but any other developer can.
The "ppt" branch is now merged. FWIW, a Linux build of the current trunk is not crashing on the provided PPT file.
(In reply to Arrigo Marchiori from comment #8) > The "ppt" branch is now merged. > > FWIW, a Linux build of the current trunk is not crashing on the provided PPT > file. Windows builds still crash.
I made some tests on Windows too and found it crashing due to some memory corruption, or at least it looked like that. I personally find using WinDbg painful... I wish we could reproduce this issue on Linux.
I can provide Windows crashdumps, if helpful.
The latest trunk still crashes on FreeBSD/amd64, with the same kind of stack trace I posted in comment 6. Note how even in that comment: #14 0x000000080e6d36fc in SdPage::SetAutoLayout(AutoLayout, unsigned char, unsigned char) (this=0x8, eLayout=<optimized out>, bInit=1 '\001', bCreate=<optimized out>) at source/core/sdpage.cxx:1575 This "this=0x8" is definitely wrong. Also frame 15 passes different values to that method to what frame 14 sees. If we put a breakpoint on the frame 15 line of code, and step into the frame 14 method, the frame 14 parameters are passed and received correctly. In other words, STACK CORRUPTION occurs later, corrupting the stack as deep as frame 14!!! This is then a potential security issue too.
It works in Valgrind, crashes outside Valgrind... probably uninitialized memory access or something.
Windows does not crash in commit 2ed47956e3ec22116d5164494008afeac3f699a1 from 29 August 2015, suggesting a regression after that point in time. It would be helpful to bisect this bug and bug 127861 together.
(In reply to damjan from comment #14) > Windows does not crash in commit 2ed47956e3ec22116d5164494008afeac3f699a1 > from 29 August 2015, suggesting a regression after that point in time. It > would be helpful to bisect this bug and bug 127861 together. I'm available to help, but I have no idea what is bisecting and how to bisect two bugs at the same time. As a marine biologist I'm more familiar with dissecting :)
(In reply to Pedro from comment #15) > (In reply to damjan from comment #14) > > Windows does not crash in commit 2ed47956e3ec22116d5164494008afeac3f699a1 > > from 29 August 2015, suggesting a regression after that point in time. It > > would be helpful to bisect this bug and bug 127861 together. > > I'm available to help, but I have no idea what is bisecting and how to > bisect two bugs at the same time. As a marine biologist I'm more familiar > with dissecting :) You can't really bisect 2 bugs at the same time, but you can do multiple tests on each step of the bisect for 1 bug to reduce the number of steps for any other bugs. For example, using + to denote bug presence or - to denote bug absence, we knew both regressions happened between 2015 and 2018: Year 2015 2018 +-----------------------------------------------+ 127738- 127738+ 127861- 127861+ And after testing a commit in year 2017 and getting this result: Year 2015 2017 2018 +------------------------+----------------------+ 127738- 127738- 127738+ 127861- 127861- 127861+ I now know both regressions happened after that 2017 commit, so when I bisect bug 127861, I can start from 2017 instead of 2015, reducing the number of bisect steps.
(In reply to damjan from comment #16) > You can't really bisect 2 bugs at the same time, but you can do multiple > tests on each step of the bisect for 1 bug to reduce the number of steps for > any other bugs. > Yes, I understand the logic. I was not expecting that you would test 1069 steps one by one :) My point was, since I can't dissect those bugs, let me know what I can do to help. As this is a Windows only bug, I will have to wait for Matthias' builds to test...
On FreeBSD I couldn't reproduce any PPT crashes using: db54ab87120ff0d8e8b488a3aea635318583b1f4 2017-12-02 e74cb447ea3816bfc4b366ebc4fba3b638e9c65a 2017-08-05 db54ab87120ff0d8e8b488a3aea635318583b1f4 2017-12-02 8d1a3dfa5ab64f51ad85a7ce8d7a0a855595e2ab 2019-01-01 but latest trunk does crash now, and in comment 6 I did notice it crashing in 2023-01-17 too. So then sadly we have AT LEAST 2 (!!!) PPT crashing bugs: 1. The Windows-only bug originally described here that started around 2018. 2. A FreeBSD (and what other systems?) bug that started between 2019-01-01 and 2023-01-17.
(In reply to damjan from comment #18) > So then sadly we have AT LEAST 2 (!!!) PPT crashing bugs: > 1. The Windows-only bug originally described here that started around 2018. > 2. A FreeBSD (and what other systems?) bug that started between 2019-01-01 > and 2023-01-17. That new regression I discovered is now being tracked as bug 128579. Let's leave this bug to deal with the original Windows-only crash.
Windows is crashing on this PPT file as early as 317f9b584f95bf6763550cd0ddfdd08cd5ef1b97 from 9 August 2016 which just after the gbuild-reintegration branch merge, but wasn't crashing in 2ed47956e3ec22116d5164494008afeac3f699a1 from 29 August 2015. So did the regression happen within trunk, or was it merged in from the gbuild-reintegration branch, possibly originating from the old commits by Sun/Oracle? trunk ^ | + 317f9b584f95bf6763550cd0ddfdd08cd5ef1b97 [BAD] | 9 Aug 2016 | + b63233d868a9af170b0457a7aa0c5809011cc2c1 [?] /| 7 Aug 2016 / | / + f1d7d1c02075b181fb9e6b602d2923ea341d9bba [?] / | / | / | / ^ / | / ^ / | gbuild-reintegration [?] ^ | | | +- 2ed47956e3ec22116d5164494008afeac3f699a1 [GOOD] | | 29 August 2015 | | | trunk | | gbuild [?]
It crashes even on f1d7d1c02075b181fb9e6b602d2923ea341d9bba, the commit just before the gbuild-reintegration branch was merged: trunk ^ | + 317f9b584f95bf6763550cd0ddfdd08cd5ef1b97 [BAD] | 9 Aug 2016 | + b63233d868a9af170b0457a7aa0c5809011cc2c1 [?] /| 7 Aug 2016 / | / + f1d7d1c02075b181fb9e6b602d2923ea341d9bba [BAD] / | 5 Aug 2016 / | / | / ^ / | / ^ / | gbuild-reintegration [?] ^ | | | +- 2ed47956e3ec22116d5164494008afeac3f699a1 [GOOD] | | 29 August 2015 | | | trunk | | gbuild [?] So the regression must be somewhere between 29 August 2015 and 5 August 2016.
Finally found it: ---snip--- 8e9316519fe7ab9e74737e9e8cf250d9ecfba643 is the first bad commit commit 8e9316519fe7ab9e74737e9e8cf250d9ecfba643 Author: Pedro Giffuni <pfg@...> Date: Sun Nov 29 20:44:03 2015 +0000 Resource Leak CID: 736452 git-svn-id: https://svn.apache.org/repos/asf/openoffice/trunk@1717120 13f79535-47bb-0310-9956-ffa450edef68 ---snip--- Adding author to CC. The problem is here: ---snip--- ::osl::Module* pLibrary = OpenLibrary( mrMedium.GetFilter()->GetUserData() ); if ( pLibrary ) { ImportPPT PPTImport = reinterpret_cast< ImportPPT >( pLibrary->getFunctionSymbol( ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "ImportPPT" ) ) ) ); if ( PPTImport ) bRet = PPTImport( aTraceConfigPath, &aConfigData, &mrDocument, *pDocStream, *pStorage, mrMedium ); if ( !bRet ) mrMedium.SetError( SVSTREAM_WRONGVERSION, ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( OSL_LOG_PREFIX ) ) ); } delete pLibrary; ---snip--- The last line, "delete pLibrary", was added by this bad commit, and it deletes the pLibrary pointer whether it is NULL or not, which will end up doing "delete NULL" when it's NULL, and crash. The "delete pLibrary" should probably be at the end of the "if" block just above it instead.
(In reply to damjan from comment #22) > The last line, "delete pLibrary", was added by this bad commit, and it > deletes the pLibrary pointer whether it is NULL or not, which will end up > doing "delete NULL" when it's NULL, and crash. That's NOT the problem, pLibrary isn't NULL and moving "delete pLibrary" inside the prior "if" block still crashes. Only removing it stops the crash. Calling "pLibrary->unload()" instead also crashes. What on earth is going on?
A stupid question.would a try block help catching the crash? Maybe we can then call an abort function. It does not fix the issue but handle the crash. As a quick fix.
I can confirm that after removing Pedro's two commits I could load PPTs with AOO 4.2.0 on Windows 10. (I have still one PPT that crashes AOO but that might be another problem. We still need to address the resource leak. Maybe looking at Coverity (CID: 736452) could be helpful?
Installing gdb in Cygwin and running soffice.bin under gdb, shows the crash location: ---snip--- Program received signal SIGSEGV, Segmentation fault. 0x0315f33c in svxcore!?ImpProcessObj@SdrObjListIter@@AAEXPAVSdrObject@@W4SdrIterMode@@E@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/svxcore.dll (gdb) bt #0 0x0315f33c in svxcore!?ImpProcessObj@SdrObjListIter@@AAEXPAVSdrObject@@W4SdrIterMode@@E@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/svxcore.dll #1 0x0315f320 in svxcore!?ImpProcessObjectList@SdrObjListIter@@AAEXABVSdrObjList@@W4SdrIterMode@@E@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/svxcore.dll #2 0x0315f3e6 in svxcore!??0SdrObjListIter@@QAE@ABVSdrObjList@@W4SdrIterMode@@E@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/svxcore.dll #3 0x07a58818 in ?? () #4 0x0f591452 in ?? () #5 0x0f595de0 in ?? () #6 0x0f4b2e0f in ?? () #7 0x0f4b2fa7 in ?? () #8 0x0f4d7ae5 in ?? () #9 0x0f771809 in ?? () #10 0x0f77192c in ?? () #11 0x0f77239a in ?? () #12 0x0f763444 in ?? () #13 0x0f764b6b in ?? () #14 0x0f76391f in ?? () #15 0x0f765b16 in ?? () #16 0x0f765ec1 in ?? () #17 0x0f7661ff in ?? () #18 0x0f756e0e in ?? () #19 0x0f528554 in ?? () #20 0x0f51522a in ?? () #21 0x0382bec4 in sfx!?CreateInstance@SfxViewFactory@@QAEPAVSfxViewShell@@PAVSfxViewFrame@@PAV2@@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #22 0x07a3c628 in ?? () #23 0x037c4221 in sfx!?createViewController@SfxBaseModel@@UAA?AV?$Reference@VXController2@frame@star@sun@com@@@uno@star@sun@com@@ABVOUString@rtl@@ABV?$Sequence@UPropertyValue@beans@star@sun@com@@@3456@ABV?$Reference@VXFrame@frame@star@sun@com@@@3456@@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #24 0x07a3c628 in ?? () #25 0x03820387 in sfx!?SetPresentationMode@SfxFrame@@QAEXE@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #26 0x08840868 in ?? () #27 0x03820a8f in sfx!?SetPresentationMode@SfxFrame@@QAEXE@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #28 0x018df06c in ?? () #29 0x082bdd19 in ?? () #30 0x082bde5c in ?? () #31 0x08281d37 in ?? () #32 0x08281f78 in ?? () #33 0x019330af in comphelpMSC!?dispatch@SynchronousDispatch@comphelper@@SA?AV?$Reference@VXComponent@lang@star@sun@com@@@uno@star@sun@com@@ABV?$Reference@VXInterface@uno@star@sun@com@@@4567@ABVOUString@rtl@@1JABV?$Sequence@UPropertyValue@beans@star@sun@com@@@4567@@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/comphelpMSC.dll #34 0x0883ecb0 in ?? () #35 0x036942e7 in sfx!?OpenDocExec_Impl@SfxApplication@@QAEXAAVSfxRequest@@@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #36 0x018df53c in ?? () #37 0x0368e9e5 in sfx!??ASfxInterface@@ABEPAVSfxSlot@@G@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #38 0x0384163e in sfx!?Call_Impl@SfxDispatcher@@AAEHAAVSfxShell@@ABVSfxSlot@@AAVSfxRequest@@E@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #39 0x0780d0f8 in ?? () #40 0x03841b51 in sfx!?_Execute@SfxDispatcher@@IAEXAAVSfxShell@@ABVSfxSlot@@AAVSfxRequest@@G@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #41 0x0780d0f8 in ?? () #42 0x038422af in sfx!?Execute@SfxDispatcher@@QAEPBVSfxPoolItem@@GGGABVSfxItemSet@@@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #43 0x0780d0f8 in ?? () #44 0x03843189 in sfx!?Execute@SfxDispatcher@@QAEPBVSfxPoolItem@@GGABVSfxItemSet@@@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #45 0x036929d3 in sfx!?OpenDocExec_Impl@SfxApplication@@QAEXAAVSfxRequest@@@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #46 0x0000157d in ?? () #47 0x00000001 in ?? () #48 0x079924f0 in ?? () #49 0x0368e9e5 in sfx!??ASfxInterface@@ABEPAVSfxSlot@@G@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #50 0x0384163e in sfx!?Call_Impl@SfxDispatcher@@AAEHAAVSfxShell@@ABVSfxSlot@@AAVSfxRequest@@E@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #51 0x0780d0f8 in ?? () #52 0x038425ae in sfx!?PostMsgHandler@SfxDispatcher@@AAEJPAVSfxRequest@@@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #53 0x0780d0f8 in ?? () #54 0x0384319b in sfx!?LinkStubPostMsgHandler@SfxDispatcher@@CAJPAX0@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #55 0x01bd2617 in tl!?Call@Link@@QBEJPAX@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/tl.dll #56 0x037d95c1 in sfx!?InitializeHelp@SfxVirtualMenu@@QAEXXZ () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #57 0x018dfa44 in ?? () #58 0x037d95de in sfx!?InitializeHelp@SfxVirtualMenu@@QAEXXZ () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/sfx.dll #59 0x01bd2617 in tl!?Call@Link@@QBEJPAX@Z () from /cygdrive/c/source/openoffice-git/main/instsetoo_native/wntmsci12/Apache_OpenOffice/installed/install/en-US/OpenOffice 4/program/tl.dll ---snip--- Note how it's in svxcore.dll, far from where the bad commit is, and happens later. Coverity shows us what we already know, the library isn't unloaded and leaks: https://scan5.scan.coverity.com/reports.htm#v60608/p10187/fileInstanceId=60162852&defectInstanceId=18554376&mergedDefectId=736452
Created attachment 87221 [details] Just a sample MS Spreadsheet to use for testing Unfortunately PPT files still crash Dev5 but if an MS spreadsheet (xls or xlsx) such as this one, the crash does not occur.
(In reply to Pedro from comment #27) > Created attachment 87221 [details] > Just a sample MS Spreadsheet to use for testing > > Unfortunately PPT files still crash Dev5 but if an MS spreadsheet (xls or > xlsx) such as this one, the crash does not occur. Sorry, I missed some words "such as this one _is opened before_, the crash does not occur.