Issue 79962 - crash when running integration test qa.integration.forms.RadioButtons
Summary: crash when running integration test qa.integration.forms.RadioButtons
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: 680m222
Hardware: All All
: P2 Trivial (vote)
Target Milestone: OOo 2.3
Assignee: steffen.grund
QA Contact: issues@dba
Keywords: regression
: 80500 (view as issue list)
Depends on:
Reported: 2007-07-24 12:27 UTC by Frank Schönheit
Modified: 2009-07-20 15:17 UTC (History)
1 user (show)

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

stack of the crash (2.00 KB, text/plain)
2007-07-24 12:28 UTC, Frank Schönheit
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2007-07-24 12:27:27 UTC
- start OOo with -accept=socket,host=localhost,port=8100;urp
- run the integration test qa.integration.forms.RadioButton
  (by issueing "dmake", then "dmake run_RadioButton" in forms/qa/integration/forms,
  or create a respective NetBeans project)
=> OOo crashes
Comment 1 Frank Schönheit 2007-07-24 12:28:29 UTC
Created attachment 47027 [details]
stack of the crash
Comment 2 Frank Schönheit 2007-07-24 12:42:51 UTC
fs->mba: I strongly suppose this has to do with the SfxBaseModel refactoring
which was integrated in m222 - the bug does not happen in m221.

While I have not been able to manually reproduce the crash, I am uncertain
whether it would be possible to encountered it outside the test case. I suppose
it *is* possible, so I target the issue to 2.3.

The attached stack shows that SfxBaseModel::getArgs accesses a "semi-dead"
IMPL_SfxBaseModel_DataContainer struct, i.e. one which is currently being
Comment 3 Frank Schönheit 2007-07-24 12:43:40 UTC
fs->cd: as agreed, please take over for MBA
Comment 4 Mathias_Bauer 2007-07-24 18:53:37 UTC
The problem is that the container releases the added listeners while it is
destroyed, but the Model will not know that it is being disposed until the end
of the dispose() method. The correct fix would be to replace



IMPL_SfxBaseModel_DataContainer pData = m_pData;
m_pData = 0;
delete pData;

Of course dbtools::isEmbeddedInDatabase() must be prepared for the
DisposedException it will get!

Comment 5 Mathias_Bauer 2007-07-24 19:42:14 UTC
BTW: IMHO it's much too much what happens in the dtor of an ObjectShell and
especially in the dtor of DrawingModel! 

Rereading my first comment I was afraid I could be misunderstood: the
"container" is m_pData and the "listener" is m_pObjectShell; I was not talking
about UNO listeners and containers here.

BTW II: IMHO it's a bug in dbtools that it still keeps a reference to the model
though it already had asked for disposing of it (you must register as a
DisposeListener if you keep a reference to a model as it is an XComponent!). Or
where does it get the model from its calls "getArgs()" on?
Comment 6 Frank Schönheit 2007-07-24 20:37:48 UTC
> Or where does it get the model from its calls "getArgs()" on?

It travels the object hierarchy upwards. That is, it basically calls getParent
at the form control model, until it finds an XModel. And yes,
isEmbeddedInDatabase is "prepared" for an DisposedException in that it silences it.
Comment 7 carsten.driesner 2007-07-25 07:31:02 UTC
cd: Fixed.
Comment 8 carsten.driesner 2007-07-30 08:32:23 UTC
cd->cn: Please verify.
Comment 9 Olaf Felka 2007-07-30 14:32:03 UTC
Reassigned for verification.
Comment 10 steffen.grund 2007-08-01 15:24:27 UTC
Checked on Windows and Solaris, test works -> verified.
Comment 11 Frank Schönheit 2007-08-21 12:34:41 UTC
*** Issue 80500 has been marked as a duplicate of this issue. ***
Comment 12 thorsten.ziehm 2009-07-20 15:17:47 UTC
This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
If you want to know more about the handling of fixed/verified issues =>