16

glibc を使用するライブラリを使用しているとしましょう。Valgrind で実行中にプログラムを終了すると、あらゆる種類のメモリ リークが Valgrind によって検出されます。私が書いたばかりの数行のコードに明示的に関連するリークはないと 100% 確信しています。他のライブラリからのリークを抑制し、リーク検出を直接のコードに制限する方法はありますか?

例えば：

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)
4

2 に答える 2

13

任意のlibディレクトリ（/ lib、/ lib64、/ usr / lib、/ usr / lib64、...）の下にあるすべての共有ライブラリのリークエラーを無視するには、これをファイルに入れて、次のコマンドでvalgrindに渡します。--suppressions=*FILENAME*

{
   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.*
}

...しかし、これにより、Valgrindmallocを使用するライブラリによる呼び出しのエラーが明らかになります。valgrind mallocはプログラムテキストに直接挿入されるため（ダイナミックライブラリとしてロードされない）、独自のコードと同じようにスタックに表示されます。これにより、Valgrindは割り当てを追跡できますが、要求したことを正確に実行することも困難になります。

参考：valgrind3.5を使用しています。

上記は、この質問の本文で尋ねられる、少し古い、わずかに異なる質問への回答の抜粋です（したがって、タイトルは少し不十分です）。

于 2013-02-08T21:47:53.767 に答える
2

Valgrind の Web サイトで抑制のトピックを調べてください。サードパーティ ライブラリからのエラーを抑制したい。

于 2011-08-14T05:34:06.573 に答える