用Valgrind调试GTK程序及其它Tips
作者：刘旭晖 Raymond转载请注明出处
Email：colorant@163.com
BLOG：http://blog.csdn.net/colorant/
如何使用Valgrind的文章很多了，我也不打算再写一个，这里只是记录一下自己在调试GTK程序过程中遇到的一些问题，以及其它一些Tips
1.1 排除虚假的内存泄露问题
当使用Valgrind调试基于GTK或GLIB Library的程序时候，很容易在输出结果中出现一大堆的内存泄露内容，这里面有很大一部分并不是由你的程序所导致真正的内存泄露问题，而是因为例如内存分配的Slice机制，或着底层库函数中其它一些不随着你的程序退出而释放的全局变量内存等等所导致的。
要排除这些因素的干扰，可以采用以下一些方法：
首先，设置环境变量 G_SLICE和G_DEBUG排除由内存分配机制带来的影响：
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --leak-check=full your_program
其次，排除一些底层库带来的memory leak的干扰，这可以使用 –suppressions=suppression-file 来加载忽略规则文件。你可以在这里http://www.gnome.org/~johan/gtk.suppression 找到一个针对GTK 2.12的suppression文件。
当然，2.12的版本已经很老了，所以你可以自己制作suppression文件，suppression文件的格式参考这里：http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress 那么如何判断一个内存泄露问题是真的还是假的从而制作suppression文件呢？一个简单的办法是使用带--gen-suppressions=yes 参数的valgrind来检测一个简单的GTK Demo程序，自动生成一个suppression文件。然后使用这个文件来调试你自己的程序，这样虽然不能保证不会错误的放过底层库中真正的内存泄露问题，但是至少和你自己的程序代码无关，可以让你集中精力先解决自己代码的问题 ；）
需要注意的是，自动生成的suppression文件可能需要一定的修改，比如去除valgrind的注释，增减函数调用栈长度使得结果更加通用化等。
1.2 从Valgrind中得到更有用的信息
为了能够从Valgrind的输出结果中得到更加有用的信息，需要用CFLAGS="-O0 -g3"来编译你的程序，从而得到具体的调试信息。
其次，如果你的程序代码函数调用关系比较复杂，可能还需要使用 --num-callers=<number> 参数来增加函数调用堆栈的深度（默认为12），便于定位真正发生内存泄露的代码位置。