> From: Tristan Van Berkom [mailto:tristan@xxxxxxxxxxxxxxxx] > Sent: 10. februar 2015 08:25 > To: Norman, Anders > Cc: gtk-list@xxxxxxxxx > Subject: RE: Memory leak in gdbus-codegen generated code > > On Tue, 2015-02-10 at 06:59 +0000, Norman, Anders wrote: > > Well, I consider it a leak and need it cleaned up. > > > > Yes, some people stubbornly think that, however it's entirely unfounded. > > In languages with OO features built in, the data attached to a type > definition (a class) is loaded with the binary generally, in C there is > no such thing, so this data which defines a type is initialized > once-off, the first time you register a type. I'm quite new to glib/gdbus, but I would presume that if I instanciate two skeletons of the same class, the signal instances are different. Hence, the signals are instance/object data and not class data. > > > In gobject.c g_object_base_class_finalize() there is a call to > _g_signals_destroy() but I don't see exactly how this ties into the type > system of glib. > > Yes, classes can be finalized, by way of a convoluted thing which is > types which are defined to be 'dynamic' and not static, there is even > a the GTypePlugin or GTypeModule API which is intended to unregister > dynamic types when a 'plugin is unloaded'. > > However it turns out that this practice is just more headache than > it's worth, if an application requires plugins, instead performing > the dlopen once and never closing it, even when the plugin is > virtually 'unloaded' is a better practice all around (simply > disposing any plugin *instances* at unload time and keeping the > actual module loaded and ready for the next time it's 'loaded'). > > In any case, as the dbus object skeletons are most probably > registered as static types, as most type are, you will not > be able to free the memory you want to free (and even if you > did, you would still have the interned strings as a result of > signal and property declarations in memory which cannot be > 'uninterned'). > > Your best bet is to add the appropriate suppressions to your > valgrind setup and focus on catching the leaks with are, in > fact, actually leaks. > > Cheers, > -Tristan > > > > > > Anders > > > > -----Original Message----- > > From: Tristan Van Berkom [mailto:tristan@xxxxxxxxxxxxxxxx] > > Sent: 9. februar 2015 16:35 > > To: Norman, Anders > > Cc: gtk-list@xxxxxxxxx > > Subject: Re: Memory leak in gdbus-codegen generated code > > > > On Tue, 2015-02-10 at 00:32 +0900, Tristan Van Berkom wrote: > > > On Mon, 2015-02-09 at 15:05 +0000, Norman, Anders wrote: > > > [...] > > > > But the application ends up leaking the signal generated in > `dbus_foo_default_init()` which looks like this: > > > > > > > > static void > > > > dbus_foo_default_init (DbusFooIface *iface) > > > > { > > > > /* GObject signals for incoming D-Bus method calls: */ > > > > /** > > > > * DbusFoo::handle-bar: > > > > * @object: A #DbusFoo. > > > > * @invocation: A #GDBusMethodInvocation. > > > > * > > > > * Signal emitted when a remote caller is invoking the <link > linkend="gdbus-method-com-example-foo.Bar">Bar()</link> D-Bus > method. > > > > * > > > > * If a signal handler returns %TRUE, it means the signal handler will > handle the invocation (e.g. take a reference to @invocation and eventually > call dbus_foo_complete_bar() or e.g. > g_dbus_method_invocation_return_error() on it) and no order signal > handlers will run. If no signal handler handles the invocation, the > %G_DBUS_ERROR_UNKNOWN_METHOD error is returned. > > > > * > > > > * Returns: %TRUE if the invocation was handled, %FALSE to let other > signal handlers run. > > > > */ > > > > g_signal_new ("handle-bar", > > > > G_TYPE_FROM_INTERFACE (iface), > > > > G_SIGNAL_RUN_LAST, > > > > G_STRUCT_OFFSET (DbusFooIface, handle_bar), > > > > g_signal_accumulator_true_handled, > > > > NULL, > > > > g_cclosure_marshal_generic, > > > > G_TYPE_BOOLEAN, > > > > 1, > > > > G_TYPE_DBUS_METHOD_INVOCATION); > > > > > > > > } > > > > > > > > Am I using the generated code wrong or is it a bug in glib/gdbus- > codegen? > > > > > > This is not considered a leak, a signal connection leaking would be a > > > leak, but a signal declaration as such, is expected to be kept with > > > the statically registered GTypeInstance. > > > > Err, I should have just said GType, the GTypeInstance is indeed instance > data and freed with every object, sorry for the confusion. > > > > Cheers, > > -Tristan > > > > > > This message is subject to the following terms and conditions: MAIL > DISCLAIMER<http://www.barco.com/en/maildisclaimer> > > _______________________________________________ > > gtk-list mailing list > > gtk-list@xxxxxxxxx > > https://mail.gnome.org/mailman/listinfo/gtk-list > This message is subject to the following terms and conditions: MAIL DISCLAIMER<http://www.barco.com/en/maildisclaimer> _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
