Issue 98788 - CWS aw063: Crash when deleting inserted file slide
Summary: CWS aw063: Crash when deleting inserted file slide
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: DEV300 m39
Hardware: All All
: P2 Trivial (vote)
Target Milestone: OOo 3.1
Assignee: wolframgarten
QA Contact: issues@graphics
Depends on:
Reported: 2009-02-03 12:20 UTC by wolframgarten
Modified: 2009-02-26 10:32 UTC (History)
1 user (show)

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

bgudoc (10.50 KB, application/vnd.oasis.opendocument.presentation)
2009-02-03 12:24 UTC, wolframgarten
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description wolframgarten 2009-02-03 12:20:32 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.
Comment 1 wolframgarten 2009-02-03 12:24:36 UTC
Created attachment 59854 [details]
Comment 2 wolframgarten 2009-02-03 12:35:38 UTC
Reassigned, wrong owner ;-(
Comment 3 Armin Le Grand 2009-02-04 12:28:27 UTC
AW: Noting commit revisions (svx:267274, svtools:267375, 267376, sw: 267377
sc:267378, chart2:267379
Comment 4 Armin Le Grand 2009-02-04 13:16:09 UTC
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...
Comment 5 clippka 2009-02-04 13:22:11 UTC
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).
Comment 6 Armin Le Grand 2009-02-05 11:24:31 UTC
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...
Comment 7 Armin Le Grand 2009-02-05 14:41:34 UTC
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.
Comment 8 Armin Le Grand 2009-02-10 13:31:19 UTC
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...
Comment 9 Armin Le Grand 2009-02-10 14:15:05 UTC
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...
Comment 10 Armin Le Grand 2009-02-11 11:19:06 UTC
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...
Comment 11 Armin Le Grand 2009-02-11 15:54:03 UTC
AW: Incompatible build with correcting all destructors done. Checked in. Win
version works well now. Building other systems...
Comment 12 Armin Le Grand 2009-02-11 16:37:14 UTC
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...
Comment 13 Armin Le Grand 2009-02-12 13:02:46 UTC
AW: Works as expected, fixed.
Comment 14 Armin Le Grand 2009-02-12 13:18:58 UTC
AW->WG: Please verify.
Comment 15 wolframgarten 2009-02-12 15:40:29 UTC
Verified in CWS.
Comment 16 wolframgarten 2009-02-26 10:32:17 UTC
Tested in OOO310_m3. Closed.