Sử dụng valgrind để tìm rò rỉ bộ nhớ trong máy khách mysql C++

Question

Tôi đang sử dụng valgrind để thử và theo dõi rò rỉ bộ nhớ là máy khách mysql C++ được phân phối từ mysql.

Trong cả hai ví dụ (resultset.cpp) và chương trình của riêng tôi, có một khối 56 byte duy nhất không được giải phóng. Trong chương trình của riêng tôi, tôi đã theo dõi sự rò rỉ cho một cuộc gọi đến máy khách mysql.

Dưới đây là kết quả khi tôi chạy thử nghiệm:

valgrind --leak-check=full --show-reachable=yes ./my-executable 

==29858== Memcheck, a memory error detector 
==29858== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. 
==29858== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info 
==29858== Command: ./my-executable 
==29858== 
==29858== 
==29858== HEAP SUMMARY: 
==29858==  in use at exit: 56 bytes in 1 blocks 
==29858== total heap usage: 693 allocs, 692 frees, 308,667 bytes allocated 
==29858== 
==29858== 56 bytes in 1 blocks are still reachable in loss record 1 of 1 
==29858== at 0x4C284A8: malloc (vg_replace_malloc.c:236) 
==29858== by 0x400D334: _dl_map_object_deps (dl-deps.c:506) 
==29858== by 0x4013652: dl_open_worker (dl-open.c:291) 
==29858== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==29858== by 0x4012FF9: _dl_open (dl-open.c:583) 
==29858== by 0x7077BCF: do_dlopen (dl-libc.c:86) 
==29858== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==29858== by 0x7077D26: __libc_dlopen_mode (dl-libc.c:47) 
==29858== by 0x72E5FEB: pthread_cancel_init (unwind-forcedunwind.c:53) 
==29858== by 0x72E614B: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126) 
==29858== by 0x72E408F: __pthread_unwind (unwind.c:130) 
==29858== by 0x72DDEB4: pthread_exit (pthreadP.h:265) 
==29858== 
==29858== LEAK SUMMARY: 
==29858== definitely lost: 0 bytes in 0 blocks 
==29858== indirectly lost: 0 bytes in 0 blocks 
==29858==  possibly lost: 0 bytes in 0 blocks 
==29858== still reachable: 56 bytes in 1 blocks 
==29858==   suppressed: 0 bytes in 0 blocks 
==29858== 
==29858== For counts of detected and suppressed errors, rerun with: -v 
==29858== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 6) 

Tôi có một số câu hỏi về vấn đề này:

1. Làm thế nào tôi nên giải thích các khối --show-thể truy cập?
2. Khối đó có hữu ích cho tôi để thử và không về lỗi này không?
3. Nếu khối không hữu ích, valgrind có cơ chế khác giúp tôi theo dõi rò rỉ không?
4. Nếu không, có một số công cụ khác (hy vọng OSS trên Linux) để giúp tôi thu hẹp điều này xuống không?

Thanks in advance ..

UPDATE: Dưới đây là đoạn code mà tôi tìm thấy trên hệ thống của tôi cho định nghĩa của pthread_exit. Tôi không chắc chắn rằng đây là nguồn thực sự đang được gọi. Tuy nhiên, nếu có, bất cứ ai có thể giải thích những gì có thể xảy ra không?

void 
pthread_exit (void *retval) 
{ 
    /* specific to PTHREAD_TO_WINTHREAD */ 

    ExitThread ((DWORD) ((size_t) retval)); /* thread becomes signalled so its death can be waited upon */ 
    /*NOTREACHED*/ 
    assert (0); return; /* void fnc; can't return an error code */ 
} 

Answer 1

thể truy cập chỉ có nghĩa là các khối có một con trỏ hợp lệ tham khảo chúng trong phạm vi khi chương trình thoát, mà chỉ ra rằng chương trình không rõ ràng miễn phí tất cả mọi thứ trên lối ra vì nó dựa trên hệ điều hành cơ bản để làm như vậy. Những gì bạn cần tìm kiếm là bị mất các khối, trong đó các khối bộ nhớ mất tất cả các tham chiếu đến chúng và không còn có thể được giải phóng nữa.

Vì vậy, 56 byte có thể được phân bổ chính, không giải phóng chúng một cách rõ ràng. Nội dung bạn đăng không hiển thị rò rỉ bộ nhớ. Nó cho thấy chính tất cả mọi thứ giải phóng nhưng những gì chính được phân bổ bởi vì chính giả định rằng khi nó chết, tất cả bộ nhớ sẽ được khai hoang bởi hạt nhân.

Cụ thể, nó pthread (trong chính) làm giả định này (đó là một giả định hợp lệ về darn gần tất cả mọi thứ được tìm thấy trong sản xuất được viết trong 15 năm qua). Sự cần thiết để các khối miễn phí mà vẫn có một tham chiếu hợp lệ về lối ra là một chút của một điểm tranh cãi, nhưng đối với câu hỏi cụ thể này tất cả những gì cần phải được đề cập là giả định đã được thực hiện.

Sửa

Nó thực sự pthread_exit() không làm sạch một cái gì đó lên trên lối ra, nhưng như đã giải thích nó có lẽ không cần phải (hoặc hoàn toàn có thể không thể) khi nó đạt đến điểm đó.