Debugging memleaks - valgrind suppressions & closures

["marcin saepia net" <marcin saepia net>]

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