Apache OpenOffice (AOO) Bugzilla – Issue 98788
CWS aw063: Crash when deleting inserted file slide
Last modified: 2009-02-26 10:32:17 UTC
Open a new impress. Use insert/file. Select the posted bugdoc. Only insert the 2nd slide. Switch to the 2nd (new) page. Cut the new slide. Close the file, discard the changes: Office crashes. Ok in master m39.
Created attachment 59854 [details] bgudoc
Reassigned, wrong owner ;-(
AW: Noting commit revisions (svx:267274, svtools:267375, 267376, sw: 267377 sc:267378, chart2:267379
AW: Problem found. Due to #i9762# where i made OuntlinerParaObject ref-counted and COW, in the described scenario data-parts of those objects use the SDrObject model's pool which gets destroyed when closing the Document. It's the classic problem that SfxItemSets only use a pointer to SfxItemPools and are not safe against the pool's deletion. I was thinking in many directions, e.g. clonig the pools, migrating the sub-data-objects of OutlinerParaObject, usig a static global pool at the OPO were all OPOs data objects are migrated too, etc., but al have their caveats. I will now safe the root problem: That SfxItemSets do not hold the Pool they are based on. To do this i will add a SfxItemPoolHolder and a counter to SfxItemPool. The holder will be a friend of SfxItemPool and change that counter when incarnated/changed on a pool to work on. At the SfxItemPool i will move the destructor to protected and add a static Free method (similar to SdrObject). Thus it will be possible to use the SfxItemPool as before, but also to use it over SfxItemPoolHolder when You want to be sure the pooly stays alive. The 2nd change is to use this mechanism in SfxItemSets. I will use it besides the _pPool pointer as member, so i need to change the constructors and the destructor, but do not have to touch any implementation. All in all this change will allow to hold a SfxItemSet safely and independent from knowing(guessing) it's pool's lifetime, so it will be possible to use them in Primitives (as view as possible, only in svx so far). Basic implementation done. I will now have to build incompatible from svtools to identify all calls to SfxItemPool's destructor and replace them with ::Free(..) calls instead. Preparing, building...
just like to add that his fixes the crash but the primitives still hold a valid SfxItemPool but it is the wrong one (the one from the model inside the clipboard).
AW: Built and adapted completely from svtools (now incompatible from there). Committing 2nd batch of changes (revision 267415). Adding some more runtime test (isloated with DBG_UTIL). Need once more to build due to potential incompatibel changes (e.g. in svx) during the adaptions...
AW: Build is in progress for all systems... AW->CL: That's not a problem. Primitives are defined to show the state they were created and to not change (since they need to copy needed visualisation data locally). The old ones will not be reused, but new ones will be created from the VOCs which need visualisation. All primitive usages will need to fetch updated primitives when model data of the object these are derived from change.
AW: After fighting for days to get SfxItemPools refcounted, i have to stop since it gets too dangerous and is not stable enough. The different ways the applications use ItemPools and their e.g. static defaults and secondary pools is too weak to securely overlook. I will take back all such changes and look for another way for the fix. Taken back in CWS and adding a messaging mechanism to SfxItemPool for notifying when in destruction...
AW: I will now derive BinTextObject from the SfxItemPool's messaging mechanism (SfxItemPoolUser) and implement it's method ObjectInDestruction(..). There, i will create a local clone as it is already prepared in BinTextObject. Trying if this works...
AW: Works in principle, but the messaging cannot be triggered from the destructor, e.g. for XOutdevItemPool it's much too late to trigger it in SfxItemPool::~SfxItemPool^since the user may clone and/or remove SfxItemSets from the pool in question. I will need to make the destructor protected and add a static ::Free(..) method again. Doing...
AW: Incompatible build with correcting all destructors done. Checked in. Win version works well now. Building other systems...
AW: Checked functionality while the other build are running. Works as designed; the BinTextObject(s) who indirectly use a dying pool create a local one and also destroy it cleanly. Thus, this task will be fixed with that functionality cleanly. Waiting for the other builds...
AW: Works as expected, fixed.
AW->WG: Please verify.
Verified in CWS.
Tested in OOO310_m3. Closed.