Re: [Evolution-hackers] Deadlock when accessing an in-proc address book (fwd)

[Chris Toshok <toshok ximian com>]

Oh this is interesting - I hadn't thought about what would happen with
the POA threading policies in the inproc case.  I'm guessing they're
being ignored and everything is handled on a single thread.  And, since
we're not using recursive mutexes it hangs when trying to lock the mutex
for the second time.

Just to make sure, can you respond with a backtrace from the hang?

This is kind of a sticky problem, since even if we fix this hang we'll
end up with another one when the stack unwinds to the
GNOME_Evolution_Addressbook_Book_open call, as the next line is a
g_cond_wait call (from which it'll never wake).

Michael, is there some way we can make the POA policies affect in-proc
calls as well (if they don't already?)

Chris

On Thu, 2003-11-27 at 15:18, ERDI Gergo wrote:
> I'm re-sending this because I wasn't subscribed when I sent it initially
> 
> -- 
>    .--= ULLA! =---------------------.   `We are not here to give users what
>    \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
>     `---= cactus cactus rulez org =---'
> Define (n.)  De ting you get for breaking de law.
> 
> ---------- Forwarded message ----------
> Date: Thu, 27 Nov 2003 17:46:01 +0100 (CET)
> From: ERDI Gergo <cactus cactus rulez org>
> To: evolution-hackers lists ximian com
> Subject: Deadlock when accessing an in-proc address book
> 
> Hi,
> 
> I'm looking at http://bugzilla.gnome.org/show_bug.cgi?id=127535, but there
> seems to be a deadlock problem. 
> If e.g. e_book_load_uri is called by a calendar backend (which resides in
> evolution-data-server, so the addressbook provider is going to be in the
> same process), the flow of events eventually gets to the point where it
> sends a BookOpen notification to listeners, and there's an in-proc
> listener for it.
> 
> However, e_book_load_uri locks a mutex near line e-book.c:1700:
> (simplified code by removing error checking)
> 
> 	our_op = e_book_new_op (book);
> 
> 	g_mutex_lock (our_op->mutex);
> 	corba_book = GNOME_Evolution_Addressbook_BookFactory_getBook
> 			(factory, book->priv->uri, 
> 			 bonobo_object_corba_objref (BONOBO_OBJECT (book->priv->listener)), 
> 			 &ev);
> 	GNOME_Evolution_Addressbook_Book_open (corba_book,
> 					       only_if_exists,
> 					       &ev);
> 
> 	/* wait for something to happen (both cancellation and a
> 	   successful response will notity us via our cv */
> 	g_cond_wait (our_op->cond, our_op->mutex);
> 
> 	status = our_op->status;
> 
> 	/* remove the op from the book's hash of operations */
> 	e_book_clear_op (book, our_op);
> 
> GNOME_Evolution_Addressbook_Book_open eventually leads to
> e_data_book_respond_open, which does the actualy firing of the
> notifyBookOpened one-way CORBA method.
> 
> And this is where the problem starts. For the in-proc case, the server's
> impl_notifyBackendOpened method gets called instantly, and the way it's
> implemented is that it emits a GSignal that is connected to
> e_book_response_open (which is near e-book.c:1360). And here's the code
> for e_book_response_open (again, simplified):
> 
> 	EBookOp *op = e_book_get_op (book);
> 
> 	g_mutex_lock (op->mutex);
> 
> 	op->status = status;
> 
> 	g_cond_signal (op->cond);
> 	g_mutex_unlock (op->mutex);
> 
> So it waits for op->mutex which is locked by e_book_load_uri.
> This doesn't cause a deadlock for the out-of-proc case because then,
> notifyBookOpened returns instantly (due to its oneway nature) and thus the
> mutex is unlocked by e_book_load_uri by the time e_book_response_open is
> called.
> 
> I hope the above is a detailed enough explanation of the problem that
> someone can help me in solving it. 
> 
> Thanks,
> 	Gergo