<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - binaryurp bridge termination sporadically causes DisposedException in a different bridge"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=134641">134641</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>binaryurp bridge termination sporadically causes DisposedException in a different bridge
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>Inherited From OOo
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>sdk
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>marc-oliver.straub@advantest.com
</td>
</tr></table>
<p>
<div>
<pre>Termination of an binaryurp bridge (eg. because the remote process crashes) can
cause DisposedException in a different bridge. Expectation is that different
bridges are not affected by termination of other bridges.
We had 3 processes communicating to each other using binaryurp bridges:
Process A <-> process B
Process B <-> process C
Process A and process C don't talk to each other.
Process A requests process B to execute a method. As part of this method,
process B needs to call process C:
A: call doSomethingInProcessB(), waiting for result
B: execute doSomethingInProcessB(), will now call doSomethingInProcessC()
C: idling
Process A is now terminated (due to one of its threads crashing, a kill, ...).
Process B notices that the bridge to process A has terminated and calls
ThreadPool::dispose(nDisposeId). ThreadPool::dispose(..) walks through all
JobQueues, calling JobQueue::dispose(nDisposeId).
Since the doSomethingInProcessB()-call is still being processed, the associated
JobQueue contains the nDisposeId as topmost entry in the callstack.
JobQueue::dispose(..) finds the disposeId and sets it to 0. It signals
m_cndWait so that the bridge can terminate (jobqueue.cxx:143)
Concurrently to this, the worker thread currently working on
doSomethingInProcessB() wants to call doSomethingInProcessC(). The IPC is sent
out and JobQueue::enter(..) is called to wait for the result.
JobQueue::enter(..) puts a different disposeId onto the callstack (since the
call uses a different bridge) and should block on m_cndWait.wait() to wait for
the result (jobqueue.cxx:73)
But m_cndWait has been signalled by JobQueue::dispose(), so JobQueue::enter(..)
doesn't block - but m_lstJobs is still empty (jobqueue.cxx:98). It resets the
m_cndWait and returns a nullptr, which is converted into a DisposedException by
Bridge::makeCall() (bridge.cxx:610) - even though the bridge to process C is
completely intact at this point in time.
I'd suggest the following fixes:
* JobQueue::enter() should check for job == nullptr after resetting m_cndWait
in jobqueue.cxx:98. If so, it should continue waiting instead of returning
nullptr. This will avoid the DisposedException, the call to
doSomethingInProcessC() will work correctly.
* JobQueue::enter() should check for m_lstCallstack == 0 and m_lstJob.empty()
after processing a request (jobqueue.cxx:109). This will ensure that the bridge
will correctly terminate once doSomethingInProcessB() has finished.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>