RE: Valgrind questions



Dear John,

Thanks for the suppression file. As a quick test, I've been using the "hello world" example from the Gtk docs 
page (http://developer.gnome.org/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD), compiled with "gcc test.c -g 
-Wall -O -o test `pkg-config --cflags --libs gtk+-3.0`" and setting the G_DEBUG=gc-friendly and 
G_SLICE=always-malloc environment variables. I'm then running valgrind with "valgrind 
--suppressions=./nip2.supp --leak-check=full --leak-resolution=high --log-file=vgdump ./test".

Running like that, I still get quite a few leaks detected by valgrind. Some of them are created by 
g_type_add_interface_static, which looks like another type_init leak, which we can safely ignore. So, I've 
added the following to the suppression file to kill these.

{
   type_init5
   Memcheck:Leak
   fun:*alloc
   ...
   fun:g_type_add_interface_static
}

However, there are still a few left (see the attached valgrind log). Most of these seem to be from 
libfontconfig. I could just suppress these, but don't want to risk masking any real errors.

Any advice?

Tom
________________________________________
From: jcupitt gmail com [jcupitt gmail com]
Sent: 20 September 2011 08:54
To: Thomas Harty
Cc: gtk-app-devel-list gnome org
Subject: Re: Valgrind questions

I posted this the last time this subject came up (twice last year, I
think), but I made this valgrind suppression file for my project:

 http://www.vips.ecs.soton.ac.uk/development/nip2.supp

Run with:

$ export G_DEBUG=gc-friendly

        This makes Glib clear certain memory areas after using them, too.

$ export G_SLICE=always-malloc

        This completely disables the magazine and slab allocator in Glib,
        and makes it use plain malloc()/free() instead.

$ valgrind --suppressions=/home/john/nip2.supp \
  --leak-check=yes \
  myprog ... > myprog-vg.log 2>&1

With this, I get no reported leaks in my huge (200,000 lines of C)
application on Ubuntu with current gtk+. There are some comments in
the file explaining what the various bits do. No doubt I've made some
errors :-( but perhaps it might be useful.

John


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]