CODEWITHSUNDEEP
c++cglibdbusgdbus
anorm
anorm

Reputation: 2263

How do I plug the memory leak when usign gdbus-codegen generated code?

I have an interface described in DBus Introspection XML format:

<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
                      "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
  <interface name="com.example.foo">
    <method name="Bar" />
  </interface>
</node>

I run gdbus-codegen like this:

gdbus-codegen --interface-prefix=com.example --generate-c-code=foo-dbus --c-namespace=Dbus foo.xml

I use the code like this:

int main()
{
    DbusFoo * skeleton = dbus_foo_skeleton_new();
    g_object_unref(skeleton);

    return 0;
}

But the application ends up leaking a 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);

}

My question:

How do I clean up after using the gdbus-codegen generated code?

Upvotes: 1

Views: 724

Answers (1)

Philip Withnall
Philip Withnall

Reputation: 5713

I suspect you will find that, if you run your program under valgrind using the latest GLib suppressions file (a version of which is installed in /usr/share/glib-2.0/valgrind/ on most Linux distros), there is no leak. As @ptomato said in a comment above, signals count as type data, and GObject never frees that (apart from for dynamically registered types). Type data is allocated once (when first used) and never freed. Don’t worry about it.

Upvotes: 1

Related Questions