https://bugs.freedesktop.org/show_bug.cgi?id=65478
Michael Stahl <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://issues.apache.org/o | |oo/show_bug.cgi?id=105557 Component|Database |Writer --- Comment #6 from Michael Stahl <[email protected]> --- (In reply to comment #5) > The ref-counted UNO object SwXTextField dervies from SwClient, where > SwModify holds a list of chained SwClient instances by naked pointers. > ~SwClient removes itself from that list. Modifications of SwModify's list > apparently need to be done with the solar mutex locked, but the Java > finalizer thread right, that is broken by design; the sw UNO API implementation has this problem a lot; i once started fixing it but only got a part of it fixed (see CWS swunolocking1 and issue 105557 ) > calls ~SwXTextField without the solar mutex locked. That thread can get > blocked when the SwTextField's member sw::UnoImplPtr<Impl> m_pImpl is > destroyed and ~UnoImplPtr tries to lock the solar mutex ("SolarMutexGuard > g;" at sw/inc/unobaseclass.hxx:110) while the main thread (with solar mutex > locked) is proceeding to hmm... looks like that class is only partially converted - has the UnoImplPtr member but the Impl class does not derive SwClient yet. i'll fix that when i find some time. > > +void SwXTextField::release() throw () > > +{ > > + SolarMutexGuard g; > > + SwXTextField_Base::acquire(); > > +} > > + surely release calling acquire is a typo? -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
