I've used the Clutter suppression files with some success. We should try and keep a standard set of GTK+ suppression files up to date, though. http://git.gnome.org/browse/clutter/tree/tests/data/clutter-1.0.suppressions On Wed, Nov 7, 2012 at 5:49 PM, marcin@xxxxxxxxxx <marcin@xxxxxxxxxx> wrote: > Hi all, > > I am trying to debug memleak in my software. > > 1) > > I use valgrind as a primary tool for such task but I am spammed by > tons of messages related to type initialization. I've found that both > suppression files mentioned at http://live.gnome.org/Valgrind are not > up to date. > > Is there any place for up to date valgrind suppression files? (at > least for GLib/GIO, I've found one for GStreamer in its git repo). > I've googled for a while but I am unable to find antyhing that makes > sense. > > > 2) > > I fixed all bugs that caused "definitely lost" warnings and hit the wall. > > I've noticed that a lot of "possibly lost" stack traces are related to > signals/closures: > > ==2893== 72 bytes in 1 blocks are possibly lost in loss record 6,781 of 9,985 > ==2893== at 0x4C29DB4: calloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2893== by 0x5912AE0: g_malloc0 (gmem.c:189) > ==2893== by 0x5127B18: g_closure_new_simple (gclosure.c:206) > ==2893== by 0x512907F: g_cclosure_new (gclosure.c:917) > ==2893== by 0x51400CD: g_signal_connect_data (gsignal.c:2443) > ==2893== by 0x619E7AF: soup_session_init (in > /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1.5.0) > ==2893== by 0x5149907: g_type_create_instance (gtype.c:1884) > ==2893== by 0x512E0B8: g_object_constructor (gobject.c:1849) > ==2893== by 0x512F6E3: g_object_newv (gobject.c:1713) > ==2893== by 0x512FEC5: g_object_new_valist (gobject.c:1830) > ==2893== by 0x61A0AEA: soup_session_async_new_with_options (in > /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1.5.0) > ==2893== by 0x12718556: gst_soup_http_src_start (in > /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstsouphttpsrc.so) > > > ==2893== 72 bytes in 1 blocks are possibly lost in loss record 6,771 of 9,985 > ==2893== at 0x4C29DB4: calloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2893== by 0x5912AE0: g_malloc0 (gmem.c:189) > ==2893== by 0x5127B18: g_closure_new_simple (gclosure.c:206) > ==2893== by 0x512907F: g_cclosure_new (gclosure.c:917) > ==2893== by 0x5133258: g_cclosure_new_object (gobject.c:3739) > ==2893== by 0x5132ACA: g_signal_connect_object (gobject.c:3561) > ==2893== by 0x41F83E: myapp_base_constructor (source-base.c:4016) > ==2893== by 0x422B97: myapp_net_http_constructor (source-net-http.c:531) > ==2893== by 0x512F6E3: g_object_newv (gobject.c:1713) > ==2893== by 0x512FEC5: g_object_new_valist (gobject.c:1830) > ==2893== by 0x51301D3: g_object_new (gobject.c:1545) > ==2893== by 0x422648: myapp_net_http_construct (source-net-http.c:353) > > I actually use signals to facilitate interactions between objects. My > suspicion is that closures can be somehow related to memleak. Am I > right? Is there any specific pattern I should follow when using > signals in highly multithreaded app to avoid memleak (if they could be > the memleak source)? How to interpret that valgrind complains so much > about? > > > 3) > > Are there any other tools you can recommend for such purpose? > > > Some notes: > > I call valgrind with G_SLICE=always-malloc G_DEBUG=gc-friendly > valgrind --tool=memcheck --leak-check=full --suppressions=gst.supp > > App is written in vala, compiled with valac 0.18 > > Thank you in advance, > > Marcin > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gtk-list -- Jasper _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
