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

[Not Zed <notzed ximian com>]

On Fri, 2003-11-28 at 16:12, Chris Toshok wrote:
> 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.
FWIW it wouldn' make any difference it if was a single thread or not, you'd still get a deadlock if you lock a resource then call something which calls somethign which tries to lock it again.

> 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
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers