Created attachment 103452 [details] Various Backtraces This currently always happens with my dbgutil master build. To reproduce have three consoles and run: 1. make debugrun (wait for start) 2. make gb_JunitTest_DEBUGRUN=T JunitTest_sc_unoapi 3. make gb_JunitTest_DEBUGRUN=T JunitTest_sw_unoapi This always results in a deadlock in the document close path: SwXTextDocument::close It's independent from the VCL backend. Even more disturbing are the transaction manager warning I see a few times before the deadlock: warn:fwk:21902:39:framework/source/fwi/threadhelp/transactionmanager.cxx:271: TransactionManager...: Owner instance already closed. Call was rejected! The attached document also contains a backtraces for these warnings. All of them are the same.
note: i've just removed the 25% of framework::Gate that was unused on master to make it easier to understand * the only way the Gate can be "closed" so that the thread will block in Gate::wait() is if another thread calls TransactionManager::registerTransaction() N times and blocks before calling N times TransactionManager::unregisterTransaction() unregisterTransaction() does not throw anything the only calls to both functions are from TransactionGuard which is RAII and only used on the stack => the main thread blocking on SolarMutex cannot be immediate cause of the deadlock * a self-deadlock is possible with Gate, but the only framework function on the blocking thread's stack is Frame::close() which already releases its TransactionGuard either some other thread is in framework code, or perhaps the "lost wakeups" cited in osl/conditn.hxx are to blame?
The problematic part is the sequence of steps aLock.clear() m_aPassage.wait() in Gate::wait; if an m_aPassage.set() followed by an m_aPassage.reset() would happen in between those two steps, it would keep on waiting despite the call to set(). However, as each call to m_aPassage.reset() is apparently paired with a later call to m_aPassage.set(), it looks like that should not be an issue here. I cannot reproduce the deadlock. And the backtraces of the two threads provided are apparently not enough to find the cause. Jan-Marek, if you can still reproduce, please provide backtraces of all the threads in the process.
(In reply to Stephan Bergmann from comment #2) > ... > > Jan-Marek, if you can still reproduce, please provide backtraces of all the > threads in the process. please tell if the issue is still present status --> NEEDINFO
I can't reproduce anymore.
Migrating Whiteboard tags to Keywords: ( needAdvise -> needAdvice) [NinjaEdit]
'needsConfirmationAdvice' is only used for unconfirmed bugs. Removing it from this bug. [NinjaEdit]