Issue 87197 - Office freezes when reloading documents with modified ole objects - integrated
Summary: Office freezes when reloading documents with modified ole objects - integrated
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: DEV300m2
Hardware: All All
: P2 Trivial (vote)
Target Milestone: OOo 3.0
Assignee: kla
QA Contact: issues@framework
Keywords: regression
Depends on:
Blocks: 87736
  Show dependency tree
Reported: 2008-03-18 15:15 UTC by kla
Modified: 2008-04-29 12:53 UTC (History)
5 users (show)

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

example doc with ole (12.07 KB, application/vnd.oasis.opendocument.spreadsheet)
2008-04-03 13:55 UTC, IngridvdM
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description kla 2008-03-18 15:15:12 UTC
Open Spreadsheet
create a simple chart from a datarange
File / Save as... [Name of your choice]
File / reload
Change a value from there the chart are build
File / reload -> Office freeze
Comment 1 IngridvdM 2008-04-03 13:54:06 UTC
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.
Comment 2 IngridvdM 2008-04-03 13:55:19 UTC
Created attachment 52498 [details]
example doc with ole
Comment 3 IngridvdM 2008-04-03 13:56:26 UTC
This is a regression caused by something integrated to dev300m2.
dev300m1 does not have this problem.
Comment 4 IngridvdM 2008-04-03 14:20:19 UTC
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.
Comment 5 IngridvdM 2008-04-03 17:57:17 UTC
I would nominate this as potential OOo 3.0 Beta blocker -> tracked witch issue 87736
Comment 6 Mathias_Bauer 2008-04-04 08:52:31 UTC
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. 
Comment 7 Frank Schönheit 2008-04-07 09:21:17 UTC
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.
Comment 8 mikhail.voytenko 2008-04-07 11:44:06 UTC
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.
Comment 9 Frank Schönheit 2008-04-07 20:41:07 UTC
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 :)
Comment 10 mikhail.voytenko 2008-04-09 11:34:27 UTC
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

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.
Comment 11 kla 2008-04-10 14:02:27 UTC
Seen ok in cws mav31 -> verified
Comment 12 kla 2008-04-16 09:01:28 UTC
Change Owner
Comment 13 kla 2008-04-23 12:42:10 UTC
Seen ok in m10 -> closed
Comment 14 uwe.luebbers 2008-04-24 10:58:17 UTC
Added "integrated" to the title, because it makes it much easier to work with the meta 
Comment 15 jogi 2008-04-29 12:53:14 UTC
already found in tFileReload