Giới hạn --memcheck vào mã riêng của bạn

Question

Cho phép nói rằng tôi đang sử dụng thư viện sử dụng glibc. Khi tôi thoát khỏi chương trình trong khi chạy nó thông qua Valgrind tất cả các loại rò rỉ bộ nhớ được phát hiện bởi Valgrind. Tôi chắc chắn 100% rằng không có rò rỉ nào rõ ràng liên quan đến một vài dòng mã tôi vừa viết. Có cách nào để ngăn chặn rò rỉ từ các thư viện khác và hạn chế phát hiện rò rỉ đối với mã trực tiếp của bạn không?

Ví dụ:

valgrind --tool=memcheck --leak-check=full --leak-resolution=high \ 
    --log-file=vgdump ./Main 

Trường hợp thực thi được xây dựng từ các nguồn sau đây:

// 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; 
} 

Có một log-file báo cáo như sau (phần lớn bị loại bỏ):

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

Answer 1

Để bỏ qua rò rỉ sai sót trong tất cả các thư viện chia sẻ dưới bất kỳ lib thư mục (/lib, /lib64, /usr/lib, /usr/lib64 ...), đặt điều này trong một tập tin và vượt qua nó để valgrind với --suppressions=*FILENAME*:

{ 
    ignore_unversioned_libs 
    Memcheck:Leak 
    ... 
    obj:*/lib*/lib*.so 
} 
{ 
    ignore_versioned_libs 
    Memcheck:Leak 
    ... 
    obj:*/lib*/lib*.so.* 
} 

Điều này có lẽ sẽ đủ để hạn chế memcheck chỉ báo cáo cho mã của riêng bạn. Tuy nhiên, hãy cẩn thận rằng điều này sẽ bỏ qua lỗi gây ra bởi bất kỳ cuộc gọi lại nào bạn đã viết được gọi bởi các thư viện. Bắt lỗi trong những callbacks thể gần được thực hiện với:

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

... nhưng điều này cho thấy sai sót trong cuộc gọi bằng một thư viện mà sử dụng malloc Valgrind. Kể từ khi malloc valgrind được tiêm trực tiếp vào văn bản chương trình - không được nạp như một thư viện động - nó xuất hiện trong ngăn xếp giống như cách mã của bạn làm. Điều này cho phép Valgrind theo dõi phân bổ, nhưng cũng làm cho khó hơn để thực hiện chính xác những gì bạn đã hỏi.

FYI: Tôi đang sử dụng valgrind 3.5.

Trên đây là một đoạn trích của một câu trả lời cho một già câu hỏi, hơi khác nhau mà được yêu cầu trong văn bản cơ thể của câu hỏi này (vì vậy tiêu đề là một chút không đủ):

• Is it possible to make valgrind ignore certain libraries?

Answer 2

Tra cứu chủ đề của suppressions tại trang web Valgrind; bạn muốn chặn các lỗi từ thư viện của bên thứ ba.