使用valgrind查找mysql C++客戶端中的內存泄漏

我正在使用valgrind來嘗試跟蹤內存泄漏是從mysql分發的mysql C++客戶端。使用valgrind查找mysql C++客戶端中的內存泄漏

在這兩個例子（resultset.cpp）和我自己的程序中，都有一個56字節的塊沒有被釋放。在我自己的程序中，我已經將漏洞追蹤到mysql客戶端的調用。

下面是結果，當我運行測試：

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)

我有這方面的幾個問題：

我應如何解讀 - 顯示，可達塊？
該塊對我來說是否有用，可以嘗試將錯誤歸零？
如果該塊沒有用，valgrind是否有另一種機制可以幫助我追蹤泄漏？
如果沒有，是否還有其他工具（希望Linux上的OSS）來幫助我縮小範圍？

在此先感謝..

UPDATE：這是我在我的系統上發現了pthread_exit定義的代碼。我不確定這是否是被調用的實際源。但是，如果是這樣，任何人都可以解釋什麼可能會出錯？

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

來源

2012-08-07 Homer6

可達只是意味着該塊有一個有效的指針引用它們的範圍，當程序退出，這表明程序沒有明確免費一切退出，因爲它依賴於底層操作系統上這樣做。你應該尋找的是失去了塊，其中的內存塊失去了所有對它們的引用，並且不能再被釋放。

所以，這56個字節可能是在main中分配的，並沒有明確釋放它們。您發佈的內容不會顯示內存泄漏。它顯示了主要釋放所有東西，但是主要分配了什麼，因爲主要假設當它死亡時，所有內存都將被內核回收。

具體來說，這是pthread（主要）作出這個假設（這是一個有效的假設，在近乎15年以上的寫作生產過程中發現的一切事物）。需要釋放在退出時仍然有一個有效引用的塊是有點爭議的一點，但對於這個具體問題，需要提及的一點是假設已經完成。

編輯

它實際上pthread_exit()未清理的東西了退出，但解釋它可能並不需要（或很可能不能），一旦達到這一點。

來源

2012-08-07 17:00:58

謝謝蒂姆。這絕對有幫助。關於如何找到沒有明確釋放內存的代碼行，您有任何建議嗎？你知道任何可能有助於做這件事的工具嗎？ – Homer6 2012-08-07 17:04:24

@ Homer6它實際上是pthread這樣做的，沒有什麼可以修復的（除非你想深入研究'pthread_exit（）'，尋找它，找到它，明確地釋放它）..但是那隻能修復它在你的機器上:) – 2012-08-07 17:13:17

謝謝蒂姆。我已經發布了pthread_exit的定義（或者我認爲是定義）。關於可能發生什麼的任何想法？ – Homer6 2012-08-07 17:29:03

使用valgrind查找mysql C++客戶端中的內存泄漏

回答

相關問題