Limit --memcheck к вашему собственному коду - PullRequest
Новая
       37

Limit --memcheck к вашему собственному коду

16 голосов
/ 14 августа 2011

Допустим, я использую библиотеку, которая использует 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)

Ответы [ 2 ]

13 голосов
/ 09 февраля 2013

Чтобы игнорировать Утечка ошибок в всех общих библиотеках в любом каталоге 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.*
}

... но это выявляет ошибки в вызовах библиотекой, использующей malloc Valgrind. Поскольку valgrind malloc внедряется непосредственно в текст программы - не загружается как динамическая библиотека - он появляется в стеке так же, как и ваш собственный код. Это позволяет Valgrind отслеживать распределение, но также затрудняет выполнение именно того, что вы просили.

К вашему сведению: я использую valgrind 3.5.

Выше приведен отрывок из ответа на более старый, немного другой вопрос, который задается в тексте этого вопроса (поэтому заголовок немного недостаточен):

2 голосов
/ 14 августа 2011

Посмотрите тему подавления на веб-сайте Valgrind;Вы хотите подавить ошибки из сторонней библиотеки.

...