Re: [Libreoffice] [PATCH] ScGlobal::GetAutoFormat not always required to create fresh instance

Hello Stephan, Kohei,

2012/1/7 Kohei Yoshida <kohei.yoshida@suse.com>:
> On Fri, 2012-01-06 at 19:03 +0100, Stephan Bergmann wrote:
>
> > So, I would appreciate it if some Calc aficionado could look at the
> > patch, whether it actually makes any sense.
>
> First, I have to say all this auto format code is not something I'm
> familiar with.  So, my opinion is based on what I gathered in the past
> ~10 minutes of reading how the global ScAutoFormat instance is used
> throughout the calc code.  I'm CC'ing Eike in case my answer is off the
> mark.
>
> Anyway, it's my understanding that the main problem is that the global
> ScAutoFormat instance unintentionally get instantiated in the destructor
> of ScAutoFormatObj during the termination of the cppunit?  In that case,
> what I would do is to add ScGlobal::HasAutoFormat() which simply checks
> whether the instance already exists, and if yes go on ahead and save if
> the flag is set.  When no such instance exists there is no need to save
> stuff anyway (since there is no data to save).
>
> Another advantage of this is that we wouldn't have to modify all the
> code that currently uses GetAutoFormat() expecting it to return a live
> instance at all times, and we could only modify the code in
> ~ScAutoFormatObj().
>
> Would that solve the problem you are facing?

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 problem is that I was only once able to reproduce this bug and
have now in my testing branch some debug statements but I was never
again able to reproduce the bug. IMHO it is a good idea to fix this
bug here but I think it would be a good idea to understand why we have
one object that is deleted later than it should be. I see here a place
for some really nasty crashs that are not really reproducable.

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.


Markus