Hi, On Thu, Oct 21, 2010 at 01:20:29PM +0200, Dejan Muhamedagic wrote: > On Thu, Oct 21, 2010 at 11:57:56AM +0200, Senko Rasic wrote: > > Hi, > > > > I'm replying directly to you with this, feel free to forward to the > > list. For further discussions I could also join the list. > > Yes, it would be good. > > > On 10/21/2010 11:34 AM, Dejan Muhamedagic wrote: > > >Senko Rasic proposed a patch for the client unregister which > > >would prevent a double unref of glib sources (IPC channel). > > >However, I cannot recall any deadlocks in lrmd. > > > > > >See http://www.init.hr/dev/cluster/patches/2444.diff > > > > > >Senko, is this something you observed or you just thought it > > >might occur? > > > > This is what I've observed happening whenever I had g_type_init() > > invoked either in the lrmd itself, or in the plugin. g_type_init() > > initialises the glib type system, which is needed for the dbus glib > > proxies to work. > > > > So, when g_type_init() was called earlier, the deadlock would > > eventually happen in the part of the code I patched. > > > > It should be very easy to test; just try using lrmd with > > g_type_init() and without, and it shoudl be apparent it gets blocked > > after the first request, no matter which plugin serves the req. > > Perhaps it would help to do g_type_init() on lrmd startup before > doing any glib2 related stuff (in particular the IPC). Not sure, > but it could be a problem with locking, i.e. that the deadlock > you saw was actually lrmd waiting on some mutex. lrmd is not a > threaded application and therefore has no g_thread_init(). > Apparently, g_thread_init() is needed (or recommended) before > g_type_init(). > > There's also a recent patch which enables threading within > g_type_init(): > > http://osdir.com/ml/svn-commits-list/2010-01/msg03809.html > > Could you give it a try and move g_type_init() to init_start() > before any other glib calls. Perhaps with g_thread_init() too.
Any news here? Cheers, Dejan > Though I'm not sure if this is going to work at all. > > Cheers, > > Dejan > > > >BTW, this same or very similar procedure is used by all programs > > >including pacemaker. > > > > Right, the code I commented out didn't look obviusly wrong to me (so > > I added a comment about the potential ref leak). Unfortunately I > > don't know much about lrmd internals and haven't been able to reason > > out why this would be happening. > > > > BR, > > Senko > > > > -- > > Senko Rasic, DobarKod d.o.o. <[email protected]> > > http://dobarkod.hr/ > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
