RE: Memory leak in gdbus-codegen generated code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> The base class is simply never cleaned up. Typical types registered with GType are static, meaning they aren't ever cleaned up for the entire duration of the process.
>
> Why do you need to clean up the type?
I'm making a framework which other developers will use to create applications. Yes, I can tell the developers to ignore the leak, but I think the question should be the other way around: Why do you need to leak this memory?

>
> On Mon, Feb 9, 2015 at 10:59 PM, Norman, Anders <Anders.Norman@xxxxxxxxx> wrote:
> Well, I consider it a leak and need it cleaned up.
>
> 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.
>
> 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.
>
>
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




[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux