This does not only affect charts but also other modified ole objects.
I'll attach an example calc document with a draw ole object.
Open the document, modify the ole object for example by moving the rectangle
shape and reload the document -> The office freezes.
I changed the summary accordingly.

Created attachment 52498 [details]
example doc with ole

This is a regression caused by something integrated to dev300m2.
dev300m1 does not have this problem.

The problem is the following:
In SfxBaseModel::ListenForStorage_Impl a DocumentStorageModifyListener is
created and  added to a storage for modified-notifications. The mutex from the
SfxBaseModel is given and hold per reference.
In the reload scenario now the listener object gets disposed in
SfxBaseModel::dispose() but it is not deregistered from the storage.
Later on when the storage should be released it tries to send a last modified
call to the already disposed listener which now uses the broken mutex which is a
reference to a member of the already deleted SfxBaseModel.

->fs: As you did the last changes in sfxbasemodel,cxx v 1.137 touching the
affected listener I suppose you are the best one to fix this problem. It is not
quite clear to me how to get the correct storage to deregister.

I would nominate this as potential OOo 3.0 Beta blocker -> tracked witch issue 87736

The current implementation is buggy in two aspects:

- the problem mentioned by Ingrid
- the code called in "modified" calls into sfx-code without using SolarMutex

The simplest and IMHO best fix would be to use the SolarMutex in the listener.
We don't get anything useful from using an own Mutex here. On the contrary: from
past experience we know that guarding objects with members that itself use
"Solar based" code by an own mutex creates a huge risk for crashes and
deadlocks. Only code that does not use any library like vcl, sfx2 etc. can
safely be implemented with an own mutex. Such code is a time bomb.

I don't know if the IModifiableDocument implementation in base uses an own mutex
- for the mentioned reasons I would strongly discourage to do so. But if uses
the SolarMutex somewhere in its code anyway we would benefit from using it in
the listener also.

If the Base module has a problem: then we shouldn't reuse the listener
implementation from sfx2. At the end it's only three methods, one is empty, two
are two-liners. 

fs->mav: Your decision. I just re-factored the code to re-use it in dbaccess as
well, I did not change its semantics/behavior.

Note: Base's implementation of ::storageIsModified does not use an own mutex, as
is requested by the comment DocumentStorageModifyListener::modified.

mav->fs: The problem that was introduced by refactoring is the wrongly shared mutex.
The own mutex of the listener was definitely a bug, but the correct fix in sfx2
context is usage of SolarMutex as mba has already mentioned.

It is no problem for me to introduce the fix. The question is whether the change
( using SolarMutex ) is acceptable for database that uses now the listener as well.

fs->mav: Argh, you're absolutely right ... I missed the point that in fact the
previous version of the listener had its own mutex, while I introduced sharing
the mutex with the owner object. Sorry, seems I completely forgot about this -
my fault.

That said, I am not sure the SolarMutex is a good solution here. While I see
Mathias' point that calling into SFX-code should be guarded by the SolarMutex, I
tend to not introduce such a pest (and locking the SM *is* a pest, as it over
time propagates to all components which use the component which does it) without
a real need.

My preferred solution would be to add correct lifetime handling for the listener
instance, in that it is not re-used for another storage, but disposed when the
document/storage is disposed, and re-created when needed.

However, that's at your discretion. Base should be fine with any of the
solutions, including a locked SolarMutex.

Sorry for introducing this bug. If you think the one who introduced it should
also fix it, then please feel free to re-assign the issue back to me - I will of
course let you review the fix then :)

mav->fs: No problem, bug happens. :)

Logically the listener is more related to the model than to the storage. So
since the storage must be disposed after model has disconnected from it I see no
problem to reuse the listener.

I also dislike the SolarMutex, unfortunately the SfxBaseModel implementation is
based on it. Moreover the SolarMutex usage is a result of the current sfx2
implementation. Changing this would need huge efforts. The listener should use
the same mutex as the model in this case, so until this change is done the
listener must use SolarMutex in sfx2 context. This is actually why I have asked
whether the change is acceptable for database, since it uses own mutex as I
understand.

I have commited the usage of SolarMutex to mav31 cws. So now the listener
neither takes the mutex from SfxBaseModel nor from database implementation any more.

Seen ok in cws mav31 -> verified

Change Owner

Seen ok in m10 -> closed

Added "integrated" to the title, because it makes it much easier to work with the meta 
issue

already found in tFileReload