| Summary: | crash on concurrent SwXTextDocument::dispose and SwXTextFrame::release | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Michael Stahl (allotropia) <michael.stahl> |
| Component: | Writer | Assignee: | Michael Stahl (allotropia) <michael.stahl> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | sberg.fun |
| Priority: | medium | ||
| Version: | 4.3.0.0.alpha0+ Master | ||
| Hardware: | Other | ||
| OS: | All | ||
| See Also: |
https://issues.apache.org/ooo/show_bug.cgi?id=105557 https://issues.apache.org/ooo/show_bug.cgi?id=107771 |
||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
|
Description
Michael Stahl (allotropia)
2013-12-13 21:35:45 UTC
this is essentially the same crash as the ones on the Linux-RHEL6-x86_64@14-with-check tinderbox earlier this year: the delete m_p is a double-free too, since SwXBookmark::Modify has created and released a new uno::Reference. Program terminated with signal 11, Segmentation fault. #0 0x00002aadd838683e in sw::UnoImplPtr<SwXBookmark::Impl>::~UnoImplPtr (this=0x142ba018, __in_chrg=<value optimized out>) at /home/tinderbox/master/sw/inc/unobaseclass.hxx:112 112 delete m_p; // #i105557#: call dtor with locked solar mutex Thread 1 (Thread 0x2aaddf9df700 (LWP 10234)): #0 0x00002aadd838683e in sw::UnoImplPtr<SwXBookmark::Impl>::~UnoImplPtr (this=0x142ba018, __in_chrg=<value optimized out>) at /home/tinderbox/master/sw/inc/unobaseclass.hxx:112 #1 0x00002aadd8382704 in SwXBookmark::~SwXBookmark (this=0x142b9fc0, __in_chrg=<value optimized out>) at /home/tinderbox/master/sw/source/core/unocore/unobkm.cxx:152 #2 0x00002aadd8382768 in SwXBookmark::~SwXBookmark (this=0x142b9fc0, __in_chrg=<value optimized out>) at /home/tinderbox/master/sw/source/core/unocore/unobkm.cxx:152 #3 0x00002aadc145886c in cppu::OWeakObject::release (this=0x142b9fc0) at /home/tinderbox/master/cppuhelper/source/weak.cxx:204 #4 0x00002aadd8387e1a in cppu::WeakImplHelper1<com::sun::star::rdf::XMetadatable>::release (this=0x142b9fc0) at /home/tinderbox/master/solver/unxlngx6/inc/cppuhelper/implbase1.hxx:110 #5 0x00002aadd8387c7a in cppu::ImplInheritanceHelper5<sfx2::MetadatableMixin, com::sun::star::lang::XUnoTunnel, com::sun::star::lang::XServiceInfo, com::sun::star::beans::XPropertySet, com::sun::star::container::XNamed, com::sun::star::text::XTextContent>::release (this=0x142b9fc0) at /home/tinderbox/master/solver/unxlngx6/inc/cppuhelper/implbase5.hxx:211 #6 0x00002aadd1ca404d in bridges::cpp_uno::shared::freeUnoInterfaceProxy (pEnv=0x1d83600, pProxy=0x14346440) at /home/tinderbox/master/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:43 Thread 9 (Thread 0x2aadd7106700 (LWP 10199)): #0 0x00000030b5e0e1e5 in __lll_unlock_wake () from /lib64/libpthread.so.0 #1 0x00000030b5e0a6f7 in _L_unlock_657 () from /lib64/libpthread.so.0 #2 0x00000030b5e0a65f in pthread_mutex_unlock () from /lib64/libpthread.so.0 #3 0x00002aadc05e784b in osl_releaseMutex (Mutex=0x121daa0) at /home/tinderbox/master/sal/osl/unx/mutex.c:163 #4 0x00002aadc4d2969c in vcl::SolarMutexObject::release (this=0x121a1e0) at /home/tinderbox/master/vcl/source/app/solarmutex.cxx:45 #5 0x00002aadc531ff03 in SalYieldMutex::release (this=0x121a1e0) at /home/tinderbox/master/vcl/generic/app/geninst.cxx:63 #6 0x00002aadd7bbc577 in SolarMutexGuard::~SolarMutexGuard (this=0x2aadd71050e0, __in_chrg=<value optimized out>) at /home/tinderbox/master/solver/unxlngx6/inc/vcl/svapp.hxx:433 #7 0x00002aadd88c173d in SwXTextDocument::close (this=0x13ddf430, bDeliverOwnership=1 '\001') at /home/tinderbox/master/sw/source/ui/uno/unotxdoc.cxx:583 #8 0x00002aadd1c99cfe in gcc3::callVirtualMethod (pThis=0x13ddf630, nVtableIndex=5, pRegisterReturn=0x0, pReturnTypeRef=0x1222330, bSimpleReturn=true, pStack=0x2aadd7105240, nStack=0, pGPR=0x2aadd71052e0, nGPR=2, pFPR=0x2aadd71052a0, nFPR=0) at /home/tinderbox/master/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:119 so creating a uno::Reference from "this" is not thread-safe unless we're inside a UNO method of "this". so we could fix this by: a) send EventObjects without a Source from the ::Modify methods b) put a WeakReference to "this" into all these objects and create the EventObject with that unfortunately if we're really called from a dying SwFrmFmt it's not possible to access it's WeakReference member any more from SwX*::Modify since Modify will be called from base class dtor ~SwFmt or even ~SwClient in many cases and at that point SwFrmFmt member is already dead... c) refactor SwFmt / SwFrmFmt dtors to notify from the subclass, and use the WeakReference SwFrmFmt::m_wXObject to check if it's still alive went with option b) even though it is quite cheesy, because it can be applied everywhere without doing case-by-case analysis of where exactly Modify is being called from various dtors in an inheritance hierarchy. master should be fixed for everything that already uses sw::UnoImplPtr SwXFrame/SwXTextFrame/SwXTextGraphicObject/SwXTextEmbeddedObject SwXTextTable SwXMeta/SwXMetaField SwXBookmark/SwXFieldmark SwXTextField SwXFieldMaster SwXDocumentIndexMark SwXDocumentIndex SwXTextSection SwXParagraph SwXReferenceMark SwXFootnote shall we call this fixed then, seeing as it was logged in 2013 and last comment says you implemented solution b |