On 01/09/2012 08:10 AM, Markus Mohrhard wrote:
In my opinion we have two bugs here.. The ScGlobal::ppRscStrin is
being deleted in the ScModule destructor which means that calc is no
longer open. So the question is why do we delete ScAutoFormatObj after
ScModule and the second one is that we are creating the object in the
destructor.
The ScAutoFormatObj is still held remotely when
Desktop::DeregisterServices disposes the URP connection via which the
object is held. That UNO objects are held longer than necessary is
normal, as e.g. a Java process only releases them when it decides to
garbage-collect its proxies for those objects. I assume that ScGlobal
is cleaned up also due to some disposing from within
Desktop::DeregisterServices, but the order in which things are disposed
here is indeterminate. So it can happen that Calc UNO objects are
disposed after ScGlobal has already been cleared. (It is generally
understood to be a bad idea to do anything---other than merely cleaning
up by---from within disposing/destroying UNO objects.)
This is indeed a general problem, and it can potentially cause other
problems besides the one we see with the crash at hand.
And then there might be a simple solution to both problems at the same
time. If possible we could add a variable to ScAutoformatObj storing a
sheet::SpreadsheetDocument (the uno interface behind ScModule and
therefore force the right destruction order. I did not test this idea
but I did something similar for ScDatabaseRangesObj and
ScDatabaseRangeObj to prevent the destruction of the
ScDatabaseRangesObj before the ScDatabaseRangeObj.
Three points:
1 If ScAutoFormatObj requires an ScModule (which in turn controls
ScGlobal?), then it would indeed look correct to keep a reference to an
ScModule instance with every ScAutoFormatObj instance. What one would
potentially need to look out for is ring references. (I know way to
little about the Calc architecture to know whether this is actually
relevant here.)
2 On the other hand, it might also be an error that ScAutoFormatObj
still requires an ScModule/ScGlobal during destruction (see above), in
which case the proper fix could be to fix ~ScAutoFormatObj (by somehow
redesigning the class to do the saving earlier). (And in which case
point 1 might become irrelevant---if some other protocol already
guarantees that the ScModule/ScGlobal is alive as long as an
ScAutoFormatObj may need it---, or an orthogonal issue that could be
fixed independently.)
3 And after all, the null-checking calls to GetAutoFormat would still
be dubious and should be addressed. (But again, that would become an
orthogonal issue that could be fixed independently.)
Stephan
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.