fdo#63391 deadlock on opening .odb file that auto-connects to the database

Let foo.odb be a database file that has a macro that connects to the
Database on "Open Document" event (and needs to prompt user for
user/password).

There was 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

This avoids the "order in the asynchronous events" dependency.

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.

Change-Id: Iab1bbec5d5df12bb89d027d43e498c78c92ffc32
Reviewed-on: https://gerrit.libreoffice.org/3310
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

0 files changed, 0 insertions, 0 deletions