Re: How to confirm a memory leak

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On 30 July 2016 at 20:00, Norman Goldstein <normvcr telus net> wrote:

> It seems the debug version is less confusing for valgrind, or
>
>    *** Does the debug code actually present different source code to the
> compiler?

Yes; debugging code enables various code paths that are meant to make
it easier for developers to debug GLib and GTK+.

> You mention, below, that I may need to add a few suppressions, but before
> adding another suppression, I got this far with the debug info:
>
> In /usr/src/debug/glib-2.48.1/gio/gdbusproxy.c
>
> LoadPropertiesOnNameOwnerChangedData *data;
> data = g_new0 (LoadPropertiesOnNameOwnerChangedData, 1);
> data->name_owner = g_strdup (new_owner); //<=== line 1391 Leak
>
> So it appears that data->name_owner is not being freed.

It is, if you look at the code of on_name_owner_changed_get_all_cb:

https://git.gnome.org/browse/glib/tree/gio/gdbusproxy.c#n1246

If the operation was not cancelled, the name_owner string is "stolen"
and stored inside the proxy instance structure; the name_owner field
is going to be freed when the proxy instance is finalized.

If the operation was cancelled, the name_owner string is freed.

Ciao,
 Emmanuele.

> On 30/07/16 06:58 AM, jcupitt gmail com wrote:
> > You need to set the malloc routines to use the real system malloc;
> >
> >          export G_DEBUG=gc-friendly
> >          export G_SLICE=always-malloc
> >
> > I have this suppressions file:
> >
> >           https://github.com/jcupitt/libvips/blob/master/libvips.supp
> >
> > That's for a gobject-based library, you might need to add a few things
> > to it. Run your program with:
> >
> >           valgrind --suppressions=libvips.supp --leak-check=yes
> > ./myprogram
> >
> > And hopefully you'll see "0 bytes definitely lost".
> >
> > John
> >
> >
> >
> >
> > On 28 July 2016 at 17:18, Norman Goldstein <normvcr telus net> wrote:
> > > I'd like to understand how to confirm a potential memory leak in gtk3.
> > > Valgrind shows a definite leak, and "top" shows a steadily increasing
> > > resident set size (RES).  However, as I have come to understand, due to
> > > how
> > > gtk/glib uses slices for memory management, and how the main loop of gtk
> > > plays a part, things are not as straightforward as I have just outlined.
> > > Is
> > > there a definitive guide, "How to confirm a memory leak in GTK"?  I have
> > > only seen various relevant pages on the net.
> > > _______________________________________________
> > > gtk-app-devel-list mailing list
> > > gtk-app-devel-list gnome org
> > > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]