Re: How to confirm a memory leak

[Norman Goldstein <normvcr telus net>]

Thank you for this.  I have attached the source for the code being tested.

The valgrind report, attached, was greatly pared down,
as a consequence  of your suppression file.

I ran valgrind twice:

1st time: No debug info -- 519 bytes definitely lost
2nd time: With debug info -- 7 bytes definitely lost  ## This is the one 
attached
Both times contained a
    Conditional jump or move depends on uninitialised value(s) ).

It seems the debug version is less confusing for valgrind, or

   *** Does the debug code actually present different source code to 
the compiler?

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.
From the subsequent call of g_dbus_connection_call, it seems
that data is being considered as user data, so is being expected
to be freed by whoever allocated it.  In fact, deallocation is happening,
since only data's "name_owner" field is not being freed.

In /usr/src/debug/glib-2.48.1/glib/gmem.h

#define g_new0(struct_type, n_structs)       _G_NEW (struct_type, 
n_structs, malloc0)

but this is where I lost things, as the _G_NEW macro is rather 
confusing, so I
did not get to the code that is deallocating "data".

In summary (and I hope the above is not too much analysis in a post):

   *** Why would "data" be deallocated, but not its "name_owner" field?





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