On sam., 2011-10-22 at 22:57 +0200, Jö Fahlke wrote: > tags 642397 +patch > thanks > > Hi! > > The problem, as far as I figured it out, is apparently twofold: > > 1. At some point xfpm_battery_notify() is called with some XfpmBattery > object. If notifications are enabled, it will add a source with idle > priority which holds a pointer to this object and has > xfpm_battery_notify_idle() as its callback function. > > 2. After xfpm_battery_notify() returns, the XfpmBattery object is entered > into some hash table. > > 3. Later the source invokes xfpm_battery_notify_idle(). The XfpmBattery > object that is passed as an argument is usually valid. But sometimes it > has a reference count of 0 and priv == NULL. > > What happens is that sometimes XfpmBattery object is removed from the hash and > freed between 2. and 3. Apparently my hal sends an add and an remove message > for the same battery immediately after each other. > > The attached patch fixes this by calling g_object_ref() on the > XfpmBatteryObject in xfpm_battery_notify() before g_idle_add() is called to > add the source. The corresponding unref happens unconditionally in > xfpm_battery_notify_idle() -- that function returns FALSE, which means the > source holding the pointer to the XfpmBattery object is removed after it's > callback returns. > > Please, somebody review this patch, I'm really quite new to glib and gobject > -- I may have easily overlooked something, or violated some convention. > (Like: is the source's callback always called, or are there cases where the > source gets removed without beeing called? That would create a memory leak.) > > Anyway, I'm going to run the patched xfpm for a while and will report back if > notice any further problems. > > Bye, > Jö. > By the way, does this still happen? 1.0.10-5 (uploaded on feb 2012) has a patch which might fix your issue.
Regards, -- Yves-Alexis
signature.asc
Description: This is a digitally signed message part