假设我正在使用一个使用glibc的库。当我退出程序,而通过Valgrind运行它的所有类型的内存泄漏是由Valgrind检测。我百分之百确定,没有任何泄漏与我刚刚编写的几行代码显式相关。是否有一种方法可以抑制来自其他库的泄漏,并将泄漏检测限制在您的直接代码中?
例如:valgrind --tool=memcheck --leak-check=full --leak-resolution=high
--log-file=vgdump ./Main
从以下来源构建可执行文件的位置:
// Include header files for application components.
#include <QtGui>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QWidget window;
window.resize( 320,240 );
window.setWindowTitle(
QApplication::translate( "toplevel", "Top-level Widget" ) );
window.show( );
QPushButton button(
QApplication::translate( "childwidget", "Press me"), &window );
button.move( 100, 100 );
button.show( );
int status = app.exec();
return status;
}
有一个日志文件,报告以下内容(删除了大部分内容):
==12803== Memcheck, a memory error detector
==12803== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==12803== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==12803== Command: ./Main
==12803== Parent PID: 12700
==12803==
==12803==
==12803== HEAP SUMMARY:
==12803== in use at exit: 937,411 bytes in 8,741 blocks
==12803== total heap usage: 38,227 allocs, 29,486 frees, 5,237,254 bytes allocated
==12803==
==12803== 1 bytes in 1 blocks are possibly lost in loss record 1 of 4,557
==12803== at 0x402577E: malloc (vg_replace_malloc.c:195)
==12803== by 0xA1DFA4: g_malloc (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xA37F29: g_strdup (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xB2A6FA: g_param_spec_string (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0x41F36473: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0xB3D237: g_type_class_ref (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB20B38: g_object_newv (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB212EF: g_object_new (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0x41F34857: gtk_settings_get_for_screen (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0x41ED0CB6: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0xB377C7: g_cclosure_marshal_VOID__OBJECT (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB1ABE2: g_closure_invoke (in /lib/libgobject-2.0.so.0.2600.0)
...
==12803== 53,244 bytes in 29 blocks are possibly lost in loss record 4,557 of 4,557
==12803== at 0x402577E: malloc (vg_replace_malloc.c:195)
==12803== by 0xA1DFA4: g_malloc (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xA36050: g_slice_alloc (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xA36315: g_slice_alloc0 (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xB40077: g_type_create_instance (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB1CE35: ??? (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB205C6: g_object_newv (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB212EF: g_object_new (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0x6180FA3: ??? (in /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so)
==12803== by 0x41F0CDDD: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0x41F11C24: gtk_rc_get_style (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0x4200A81F: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803==
==12803== LEAK SUMMARY:
==12803== definitely lost: 2,296 bytes in 8 blocks
==12803== indirectly lost: 7,720 bytes in 382 blocks
==12803== possibly lost: 509,894 bytes in 2,908 blocks
==12803== still reachable: 417,501 bytes in 5,443 blocks
==12803== suppressed: 0 bytes in 0 blocks
==12803== Reachable blocks (those to which a pointer was found) are not shown.
==12803== To see them, rerun with: --leak-check=full --show-reachable=yes
==12803==
==12803== For counts of detected and suppressed errors, rerun with: -v
==12803== ERROR SUMMARY: 1364 errors from 1364 contexts (suppressed: 122 from 11)
要忽略lib目录下所有共享库中的泄漏错误(/lib, /lib64, /usr/lib, /usr/lib64,…),将其放入一个文件中并通过--suppressions=*FILENAME*
传递给valgrind:
{
ignore_unversioned_libs
Memcheck:Leak
...
obj:*/lib*/lib*.so
}
{
ignore_versioned_libs
Memcheck:Leak
...
obj:*/lib*/lib*.so.*
}
这可能足以限制memcheck仅向您自己的代码报告。但是,要注意,这将忽略由库调用的您编写的任何回调引起的错误。在这些回调中捕获错误几乎可以用来完成:
{
ignore_unversioned_libs
Memcheck:Leak
obj:*/lib*/lib*.so
...
obj:*/lib*/lib*.so
}
{
ignore_versioned_libs
Memcheck:Leak
obj:*/lib*/lib*.so.*
...
obj:*/lib*/lib*.so.*
}
…但这揭示了使用Valgrind malloc的库调用中的错误。由于valgrind malloc被直接注入到程序文本中,而不是作为动态库加载,因此它在堆栈中显示的方式与您自己的代码相同。这允许Valgrind跟踪分配,但也使它更难准确地完成您所要求的。
仅供参考:我正在使用valgrind 3.5。
以上是对这个问题正文中一个更老的、略有不同的问题的回答的摘录(所以标题有点不充分):
- 有可能让valgrind忽略某些库吗?
在Valgrind网站上查找压抑主题;您想要抑制来自第三方库的错误