2011-08-14 51 views
14

可以說我正在使用一個使用glibc的庫。當我通過Valgrind運行程序時退出程序,Valgrind會檢測到各種內存泄漏。我100%肯定沒有任何泄漏與我剛寫的幾行代碼明確相關。有沒有辦法抑制其他庫的泄漏,並將泄漏檢測限制在你的直接代碼中?限制--memcheck您自己的代碼

例如:

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) 

回答

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。

以上是回答一個較舊的,稍有不同的問題被問這個問題的正文的摘錄(所以標題是有點不足):

2

在Valgrind網站上查找suppressions的主題;你想要抑制來自第三方庫的錯誤。

+1

感謝您的意見,他們網站上的文檔非常有限。我將不得不搜索如何實現它。但是,感謝您的支持 –

+0

http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress ...這也是資訊性的 –