To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=114933
User jl changed the following:
What |Old value |New value
================================================================================
Status|NEW |RESOLVED
--------------------------------------------------------------------------------
Resolution| |FIXED
--------------------------------------------------------------------------------
------- Additional comments from j...@openoffice.org Fri Oct 8 07:22:41 +0000
2010 -------
Extension manager can deadlock
Many functions of the extension manager service take a XCommandEnvironment
argument. It is used to obtain a XInteractionHandler of which the function
handle is called if necessary. XInteractionHandler::handle is provided by the
caller of the extension manager function. handle may not only be called from
the extension manager itself but also from other APIs to which the
XCommandEnvironment is passed. This is done, for example, when calling ucb
functions.
XInteractionHandler::handle can show dialogs, which require the solar mutex to
be locked. In many cases the thread that calls the handle function has already
acquired the extension manager mutex, so that this thread owns both mutexes. If
at this point another thread calls an extension manager function then it will
block when trying to acquire the extension manager mutex. It will only continue
if the first thread has completed the interaction and has eventually released
the extension manager mutex.
The problem arises if the second thread already owns the solar mutex before it
acquires the extension manager mutex. It will then be blocked by the extension
manager mutex which is held by the first thread. The first thread cannot acquire
the solar mutex in XExtensionManager::handle which is held by the second thread.
One can get in this situation when both threads already own the mutex which will
be later acquired by the other thread. For example, thread one acquires the
extension manager mutex while thread two acquires the solar mutex. At this
point, everything is fine until thread one (holding the extension manger mutex)
tries to acquire the solar mutex. It will then block and will therefore not
release the extension manager mutex. So whenever thread two (holding the solar
mutex) calls an extension manager function which acquires the extension manager
mutex then it will also block, because it it is held by thread one.
The usual solution would be to make sure that both threads acquire the the
mutexes in the same order. That is the extension manager could acquire the solar
mutex before acquiring its own mutex. However, the solar mutex is not a usual
mutex, because it may be released at different points in code. This may be OK
for VCL but makes it unusable for all other parts of the code. In the current
case this caused the deadlock: A worker thread is adding an extension and
acquires the extension manager mutex. The extension manager calls
XInteractionHanlder::handle, which acquires the solar mutex and then shows a
dialog by calling Execute. Execute releases the solar mutex and allows the main
thread to dispatch events. This triggered a vcl timer running in the main
thread. This thread owns the solar mutex and calls a function of the extension
manager. This function blocks because the extension manager mutex is held by the
worker thread. The Dialog.Execute function will then acquire again the solar
mutex, which is not possible because it is being held by the blocked main
thread. As a result, the worker thread blocks as well and cannot release the
extension manager mutex which is needed by the main thread.
To solve the problem I rearranged the code of XExtensionManager::addExtension so
that the extension manager mutex is never acquired when
XInteractionHanlder::handle is called.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@framework.openoffice.org
For additional commands, e-mail: issues-h...@framework.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org
