Issue 105557 - [sw] unocore: no destructor locking
Summary: [sw] unocore: no destructor locking
Status: ACCEPTED
Alias: None
Product: Writer
Classification: Application
Component: programming (show other issues)
Version: DEV300m60
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-02 15:00 UTC by mst.ooo
Modified: 2017-05-20 11:15 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description mst.ooo 2009-10-02 15:00:48 UTC
locking of UNO implementation in writer is completely broken in one aspect:
destructors

the destructors of UNO objects are invoked from remote bridges when the remote
side no longer references the UNO object.
currently, most UNO objects in writer do not do any locking.
worse, simply putting in a SolarMutex guard does not help:
the guard will be dropped before destructors of base classes and members are
invoked.

possible solutions:
1. make all potential base classes threadsafe
2. prohibit non-threadsafe base classes, and introduce pImpl objects that then
derive from the non-threadsafe base classes. the UNO object destructor locks
SolarMutex and explicitly deletes pImpl (auto_ptr does not work!)
3. wait for the mythical threading framework to solve all our locking problems...
Comment 1 mst.ooo 2009-10-02 15:03:42 UTC
.
Comment 2 mst.ooo 2009-12-14 14:14:12 UTC
a related problem:
various uno objects are "cached": they register as SwClient at a core object,
and there is code to iterate over the registered clients at the core object,
find the uno object, and construct a uno reference from the pointer.

carefully reviewing the design with mhu revealed that it is broken:
- thread A calls OWeakObject::release on a SwXBookmark
- thread A blocks on solar mutex (that is now in the SwXBookmark dtor)
- thread B, which has the solar mutex, iterates over the clients of a core bookmark,
   and creates a uno reference to the object
- thread B releases solar mutex
- thread A acquires solar mutex and deletes the SwXBookmark;
   now the uno reference points to deleted object

(after locking the solar mutex in the destructor of SwXBookmark, the complex
test "CheckBookmarks" still crashed on solaris due to this problem)

the best solution seems to be to put a weak reference to the uno object into the
core object (in addition to the entry in the listener list).
the weak reference is notified immediately and invalidated when the reference
count reaches 0.
Comment 3 mst.ooo 2010-01-11 13:41:06 UTC
partially fixed in CWS swunolocking1:

fixed the destructor locking and the SwClient caching problems for:
SwXDocumentIndexMark
SwXDocumentIndex
SwXFootnote
SwXHeadFootText
SwXBodyText
SwXText
SwXTextCursor
SwXParaFrameEnumeration
SwXTextRange
SwXTextRanges
SwXTextSection
SwXParagraphEnumeration
SwXParagraph
SwXBookmark
SwXReferenceMark
SwXMeta

now CheckBookmarks runs reliably on unxsoli4.
Comment 4 Marcus 2017-05-20 11:15:52 UTC
Reset assigne to the default "issues@openoffice.apache.org".