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
