Hi; On 30 July 2016 at 20:00, Norman Goldstein <norm...@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, jcup...@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 <norm...@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] _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
