https://bugs.freedesktop.org/show_bug.cgi?id=63391
Priority: medium
Bug ID: 63391
Assignee: libreoffice-bugs@lists.freedesktop.org
Summary: race condition (freeze) between "convert macros" and
"connect DB" in FileOpen event
Severity: major
Classification: Unclassified
OS: All
Reporter: lio...@mamane.lu
Hardware: All
Status: UNCONFIRMED
Version: 3.6.3.2 release
Component: Database
Product: LibreOffice
Created attachment 77759
--> https://bugs.freedesktop.org/attachment.cgi?id=77759&action=edit
More detailed notes, with full backtraces, etc
Let foo.odb be a database file that has this macro on "Open Document" event:
Sub Foo
Dim DBDocUI as Object
DBDocUI = ThisDatabaseDocument.currentController
if not DBDocUI.isConnected then
DBDocUI.connect
end if
End Sub
The effect of this macro is to immediately connect to the database when opening
foo.odb, instead of lazily waiting for something to need it. (I do that because
I then use "stmt.executeUpdate()" to set various DBMS-specific settings
automatically.)
Sometimes, but now always, when opening this file, LibreOffice freezes.
I've tracked it down to a race condition between two actions:
1) the asynchronous treatment of "OnFirstControllerConnected" in
dbaui::OApplicationController,
which tries to get dbaui::OApplicationController's mutex
2) the StarBasic macro calling dbaui::OApplicationController::connect
which needs to display a dialog (to get username and password),
and thus puts that dialog in the main thread's event queue
and waits for it ... with dbaui::OApplicationController's mutex held
Now, if "1)" is before "2)" in the event queue of the the main thread,
*but* "1)" is executed *after* "2)" has taken the lock, there is a deadlock.
Fix:
1) Make OnFirstControllerConnected synchronous.
Make sure (by taking mutex in dbaui::OApplicationController::attachFrame,
its ancestor in the call graph)
that nothing else will happen with the OApplicationController as long as it
is not finished.
---> it does not need to take mutex itself anymore
2) Change dbaui::OApplicationController::ensureConnection to do the user
prompting
WITHOUT HOLDING the mutex, and use the mutex "only" to protect actually
assigning
the connection to m_xDataSourceConnection.
Theoretically, in some race condition, we could connect twice and then
discard one connection <shrug>.
ensureConnection will never return the discarded connection, though.
(I think I got that right with respect to
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
This keeps it from locking on another condition while holding the mutex.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
