Re: Debugging memleaks - valgrind suppressions & closures

["Jasper St. Pierre" <jstpierre mecheye net>]

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 saepia net <marcin saepia net> 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 gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-list



-- 
  Jasper