Bug Hunting Session
Bug 81749 - Java UNO deadlock on document close
Summary: Java UNO deadlock on document close
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: lhm-limux
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-25 15:30 UTC by Jan-Marek Glogowski
Modified: 2016-09-19 16:48 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Various Backtraces (17.42 KB, text/plain)
2014-07-25 15:30 UTC, Jan-Marek Glogowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan-Marek Glogowski 2014-07-25 15:30:41 UTC
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.
Comment 1 Michael Stahl (CIB) 2015-05-13 21:15:42 UTC
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?
Comment 2 Stephan Bergmann 2015-06-04 12:41:59 UTC
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.
Comment 3 tommy27 2015-08-17 17:05:36 UTC
(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
Comment 4 Jan-Marek Glogowski 2015-11-06 15:40:34 UTC
I can't reproduce anymore.
Comment 5 Robinson Tryon (qubit) 2015-12-18 10:36:40 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2016-09-19 16:48:08 UTC Comment hidden (obsolete)