Apache OpenOffice (AOO) Bugzilla – Issue 109916
frm::OInterfaceContainer::fakeVbaEventsHack deadlock
Last modified: 2017-05-20 10:23:49 UTC
Executing forms/qa/unoapi on DEV300_m72-based CWS sb118 unxlngi6 non-pro once caused OOo to hang with the attached stack traces. (The first thread locked the SolarMutex in frame #22 and tries to lock a mutex in frame #8, while the second thread locked OInterfaceContainer::m_rMutex in frame #12 and tries to lock the SolarMutex in frame #10.)
Created attachment 68211 [details] stack traces
should be 3.3, since it breaks an automated test
This deadlock appears to not only happen when the second thread is in frm::OInterfaceContainer::fakeVbaEventsHack (frame #11), but also when it is in other functions within frm::OInterfaceContainer::implInsert (frame #12). Executing forms/qa/unoapi on DEV300_m74-based CWS sb120 (follow-up to sb118) unxsoli4 non-pro once caused OOo to hang with the main thread the same as in the original attached stack.txt, and the second thread slightly different at ---8<--- =>[1] __lwp_park(0x0, 0x0), at 0xfef749ab [2] mutex_lock_queue(0xfb0b2000, 0x0, 0x8066270, 0x0), at 0xfef6d937 [3] slow_lock(0xfb0b2000, 0x8066270, 0x0), at 0xfef6e224 [4] mutex_lock_impl(0x8066270, 0x0), at 0xfef6e31a [5] __mutex_lock(0x8066270, 0xfe736adc, 0xef7bd028, 0xfecabaa2), at 0xfef6e426 [6] osl_acquireMutex(Mutex = ???) (optimized), at 0xfecababd (line ~129) in "mutex.c" [7] vos::OMutex::acquire(this = ???) (optimized), at 0xfd7d1d71 (line ~60) in "mutex.cxx" [8] SalYieldMutex::acquire(this = ???) (optimized), at 0xf8fa2b16 (line ~68) in "salinst.cxx" [9] GtkHookedYieldMutex::acquire(this = ???) (optimized), at 0xfb8615b6 (line ~90) in "gtkinst.cxx" [10] SfxBaseModel::getArgs(this = ???) (optimized), at 0xf708e734 (line ~1042) in "sfxbasemodel.cxx" [11] dbtools::isEmbeddedInDatabase(_rxComponent = CLASS, _rxActualConnection = CLASS) (optimized), at 0xeeeb8a4a (line ~812) in "dbtools2.cxx" [12] frm::ODatabaseForm::setParent(this = ???, Parent = CLASS) (optimized), at 0xef2efc56 (line ~2451) in "DatabaseForm.cxx" [13] frm::OInterfaceContainer::implInsert(this = ???, _nIndex = ???, _rxElement = CLASS, _bEvents = ???, _pApprovalResult = ???, _bFire = ???) (optimized), at 0xef292b45 (line ~871) in "InterfaceContainer.cxx" [14] frm::OInterfaceContainer::insertByName(this = ???, _rName = CLASS, _rElement = CLASS) (optimized), at 0xef295529 (line ~1141) in "InterfaceContainer.cxx" [15] callVirtualMethod(0xecf4d28c, 0x9, 0x0, 0x0, 0xef7bd570, 0x4, 0x808a270, 0x894145c), at 0xf8c88971 [16] __unnamed_KARQ_jpmlLmbL::cpp_call(pThis = ???, aVtableSlot = STRUCT, pReturnTypeRef = ???, nParams = ???, pParams = ???, pUnoReturn = ???, pUnoArgs = ???, ppUnoExc = ???) (optimized), at 0xf8c8480e (line ~207) in "uno2cpp.cxx" [17] bridges::cpp_uno::shared::unoInterfaceProxyDispatch(pUnoI = ???, pMemberDescr = ???, pReturn = ???, pArgs = ???, ppException = ???) (optimized), at 0xf8c83f04 (line ~396) in "uno2cpp.cxx" [18] thisDispatch(pRemoteI = 0x921fc38, pType = 0x84e2288, pReturn = (nil), ppArgs = 0xecef7ed4, ppException = 0xecef7e94), line 173 in "stub.cxx" [19] bridges_urp::ServerMultiJob::execute(this = ???) (optimized), at 0xef8cf2df (line ~677) in "urp_job.cxx" [20] doit(job = ???) (optimized), at 0xef8cce7e (line ~69) in "urp_job.cxx" [21] cppu_threadpool::JobQueue::enter(this = ???, nDisposeId = ???, bReturnWhenNoJob = ???) (optimized), at 0xf8ce8d73 (line ~117) in "jobqueue.cxx" [22] cppu_threadpool::ORequestThread::run(this = ???) (optimized), at 0xf8ce987d (line ~193) in "thread.cxx" [23] cppu_requestThreadWorker(pVoid = ???) (optimized), at 0xf8ce924e (line ~46) in "thread.cxx" [24] osl_thread_start_Impl(pData = ???) (optimized), at 0xfecac747 (line ~266) in "thread.c" [25] _thr_setup(0xfb0b2000), at 0xfef74662 [26] _lwp_start(0x0, 0x0, 0x0, 0xfb0b2000, 0x8066270, 0xfef9e000), at 0xfef74950 ---8<---
fs->sb: Care to commit the patch I sent you to your current test framework CWS?
applied patch provided by fs as <http://hg.services.openoffice.org/cws/sb120/rev/bbd82cb87e8f>
Quoting the description of issue 111006 ("toolkit: deadlock between UnoControls"): "This deadlock appeared [...] when the fix for issue 109916 [...] was included. This might be a coincidence, or a problem with the fix for issue 109916."
Unfortunately, <http://hg.services.openoffice.org/cws/sb120/rev/bbd82cb87e8f> does not solve the problem. While the deadlock involving frm::OInterfaceContainer::fakeVbaEventsHack did not appear anymore, the deadlock described in <#desc4> still appeared (again, observed in unxsoli4 non-pro).
.
Created attachment 69014 [details] readable version of the stack in #desc4
sorry, completely missed that second stack ...
Created attachment 69015 [details] patch II
fs->sb: Since I cannot reproduce the second deadlock on my machine/CWS - care to try the attached patch on your platform/CWS?
attached i109916_II.patch applied as <http://hg.services.openoffice.org/cws/sb120/rev/d63be80af699>
@fs: please verify
looks good in CWS sb120