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.
> 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
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list
