Hi Johan, On Thu, Mar 8, 2012 at 10:32 PM, Anderson Lizardo <anderson.lizardo@xxxxxxxxxxxxx> wrote: > Hi Johan, > > On Thu, Mar 8, 2012 at 7:53 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: >> Hi Lizardo, >> >> On Thu, Mar 08, 2012, Anderson Lizardo wrote: >>> The "destroy" callback of g_dbus_add_disconnect_watch() is actually >>> never called, therefore the watcher data should be freed on >>> watcher_exit(). >> >> Wouldn't it make more sense to fix GDBus so that the destroy callback >> *is* called than to work around it like this? > > No other g_dbus_add_disconnect_watch() callers (besides this and LE > thermometer code which is also leaking and for which I have a patch as > well) use destroy callback. To me it seemed it was a known fact that > this parameter is not implemented in gdbus code, so that's why I went > this route. > > If you prefer that I implement this destroy functionality, when do you > think it should be called? Only when the watch is removed? > > Personally, I think it is better to simply remove this argument from > g_dbus_add_disconnect_watch(), if that is allowed. The caller usually > knows better when to "destroy" its own allocated resources (which may > explain why most users did not try to use this parameter?). What do > you think? Any comments? Maybe we can fix the memory leaks now and solve the gdbus API issue later? Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
