GNOME.org
 

RE: Memory leak in gdbus-codegen generated code

From: Tristan Van Berkom [mailto:tristan upstairslabs com]
Sent: 10. februar 2015 08:25
To: Norman, Anders
Cc: gtk-list gnome org
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 upstairslabs com]
Sent: 9. februar 2015 16:35
To: Norman, Anders
Cc: gtk-list gnome org
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 gnome org
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>
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]