天天看點
傳回

DEBUG神器valgrind之memcheck報告分析

memcheck怎麼運作 

valgrind --log-file=valgrind.log --tool=memcheck --leak-check=full --show-reachable=no --workaround-gcc296-bugs=yes ./mcsample arg1 arg2

–log-file 表示輸出報告檔案，可以是相對路徑或完全路徑

–tool=memcheck 做記憶體檢測就是memcheck，要知道valgrind是一個工具集

–leak-check=full 完整檢測

–show-reachable=no 是否顯示reachable詳見記憶體洩露部分，通常是no，也可以改成yes

–workaround-gcc296-bugs=yes 如果你的gcc存在對應的bug，則要設為yes，否則有誤報

最後是被檢測程式及其參數。

memcheck報告怎麼看

先來一段意外的寫錯 

int main(int argc, char *argv[])
{
    char* bigBuff = (char*)malloc[];
    free(bigBuff);
}
           
==3498== Invalid free() / delete / delete[] / realloc()
==3498==    at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3498==    by 0x8048444: main (main.cpp:19)
==3498==  Address 0x40c0500 is in the Text segment of /lib/i386-linux-gnu/libc-2.15.so
代碼錯誤的将malloc()寫成了malloc[]，相當于取得了malloc函數指針後面的位址，輸出報告告訴我們這個位址位于.text段。

可以看出報告的基本格式是：

{問題描述}   
at {位址、函數名、子產品或代碼行} 
by {位址、函數名、代碼行}
by ...{逐層依次顯示調用堆棧}
Address 0x???????? {描述位址的相對關系}

而報告的輸出文檔整體格式則可以總結為：

1. copyright 版權聲明
2. 異常讀寫報告
2.1 主線程異常讀寫
2.2 線程A異常讀寫報告
2.3 線程B異常讀寫報告
2... 其他線程
3. 堆記憶體洩露報告
3.1 堆記憶體使用情況概述(HEAP SUMMARY)
3.2 确信的記憶體洩露報告(definitely lost)
3.3 可疑記憶體操作報告 (show-reachable=no關閉)
3.4 洩露情況概述(LEAK SUMMARY)

都有哪些常見異常報告

記憶體洩漏 

int main(int argc, char *argv[])
{
    char* bigBuff = (char*)malloc();
}
           
1,024 bytes in 1 blocks are definitely lost in loss record 1 of 1
 at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
 by 0x8048414: main (main.cpp:17)

definitely lost：記憶體沒有被釋放，且沒有任何指針指向這裡。肯定洩漏了。報告給出的堆棧是記憶體被配置設定時的調用堆棧，它可以基本明确記憶體是由什麼業務邏輯建立的。

still reachable：是說記憶體沒有被釋放，盡管如此仍有指針指向，記憶體仍在使用中，這可以不算洩露。(程式退出時仍在工作的異步系統調用?)

possibly lost：是說可能有洩漏，一般是有二級指針（指針的指針）等複雜情況不易于追蹤時出現。

suppressed：統計了使用valgrind的某些參數取消了特定庫的某些錯誤，會被歸結到這裡

異常釋放 

int main(int argc, char *argv[])
{
    char* bigBuff = (char*)malloc();
    char* offsetBuff = bigBuff + ;
    free(offsetBuff);
}
           
Invalid free() / delete / delete[] / realloc()
  at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  by 0x8048461: main (main.cpp:24)
 Address 0x41f23a0 is 888 bytes inside a block of size 1,024 alloc'd
  at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  by 0x8048444: main (main.cpp:17)

free() / delete / delete[] / realloc() 四種中的任一種，這裡是free的非法釋放。在描述位址的相對關系時，使用了一個句子，句子的格式是：Address 0x???????? is {x} bytes {inside/before/after} a block of size {y} {alloc’d/free’d}

它表示了釋放的位址與一個y長度塊的相對位置關系。如果位址位于塊前，則用before，位于塊内則用inside，塊後則是after。而最後的alloc’d代表這個y長度的塊處于有效狀态，其配置設定時的棧如下；而free’d代表y長度塊已删除，其删除時的棧如下。

是以上面的報告可以解釋為：位址0x41f23a0位于一個長度1024的有效塊内+888處，其配置設定時的調用堆棧如下。

非法讀寫 

int main(int argc, char *argv[])
{
    char* bigBuff = (char*)malloc();
    uint64_t* bigNum = (uint64_t*)(bigBuff+);
    *bigNum = ;
    printf("bigNum is %llu\n",*bigNum);
    free(bigBuff);
}
           
Invalid write of size 4
 at 0x8048490: main (main.cpp:19)
Address 0x41f2428 is 0 bytes after a block of size 1,024 alloc'd
 at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
 by 0x8048474: main (main.cpp:17)

Invalid read of size 4
 at 0x804849B: main (main.cpp:20)
Address 0x41f2428 is 0 bytes after a block of size 1,024 alloc'd
 at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
 by 0x8048474: main (main.cpp:17)

對一個記憶體區的使用超過了配置設定的大小時，可以觸發Invalid write/read，同時被告知長度。本例中uint64_t有8位元組長，通路超出了4位元組。如果将bigBuff+1020改成bigBuff-20，那麼報告中會準确的告訴你Address xxx is 20 bytes before a block of …

另外一個有趣的現象是，我發現對uint64_t的非法通路會産生2次4位元組長度非法通路的報告，這說明了什麼？

不比對的釋放 

int main(int argc, char *argv[])
{
    int unused;
    char* bigBuff = (char*)malloc();
    delete[] bigBuff;
    printf("unused=%d",unused);
}
           
Mismatched free() / delete / delete []
 at 0x402A8DC: operator delete[](void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
 by 0x80484FB: main (main.cpp:19)
Address 0x4323028 is 0 bytes inside a block of size 1,024 alloc'd
 at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
 by 0x80484E4: main (main.cpp:18)

Use of uninitialised value of size 4
 at 0x416E0DB: _itoa_word (_itoa.c:195)
 by 0x417221A: vfprintf (vfprintf.c:1629)
 by 0x4178B2E: printf (printf.c:35)
 by 0x41454D2: (below main) (libc-start.c:226)
不管malloc配置設定後用delete還是delete[]，又或者是new[]之後粗心用delete釋放，都會得到Mismatched free() / delete / delete []報告，且報告主體内容基本一緻。

使用未初始的值

上例中int unused并未指派即被使用，得到了Use of uninitialised value of size 4的報告，這樣的問題通常不緻命，但是也需要排除。

可以觀察到一個有趣情況，堆棧最後一層首次出現了 (below main)，它表示代碼位于main函數以外被執行，也并非來自于線程，我還不能明确解釋這種現象，但是我做了下面這個測試：…

靜态構造和釋放 

class GlobalClass
{
public:
    GlobalClass()
    {
        char* buf = (char*)malloc(10);
        *(int*)(buf+8) = 100;
        free(buf);
    }
    ~GlobalClass()
    {
        char* buf = (char*)malloc(10);
        *(int*)(buf+8) = 100;
        free(buf);
    }
    void fake(){}
} g_globalClass;

int main(int argc, char *argv[])
{
    g_globalClass.fake();
}
           
Invalid write of size 4
 at 0x804857B: GlobalClass::GlobalClass() (main.cpp:21)
 by 0x804850F: __static_initialization_and_destruction_0(int, int) (main.cpp:31)
 by 0x8048551: _GLOBAL__sub_I_g_globalClass (main.cpp:55)
 by 0x8048631: __libc_csu_init (in /home/jinzeyu/codelocal/build-mcsample-Desktop_Qt_5_3_GCC_32bit-Debug/mcsample)
 by 0x4060469: (below main) (libc-start.c:185)
Address 0x41f2030 is 8 bytes inside a block of size 10 alloc'd
 at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
 by 0x8048571: GlobalClass::GlobalClass() (main.cpp:20)
 by 0x804850F: __static_initialization_and_destruction_0(int, int) (main.cpp:31)
 by 0x8048551: _GLOBAL__sub_I_g_globalClass (main.cpp:55)
 by 0x8048631: __libc_csu_init (in /home/jinzeyu/codelocal/build-mcsample-Desktop_Qt_5_3_GCC_32bit-Debug/mcsample)
 by 0x4060469: (below main) (libc-start.c:185)

Invalid write of size 4
 at 0x80485B9: GlobalClass::~GlobalClass() (main.cpp:27)
 by 0x4079B80: __run_exit_handlers (exit.c:78)
 by 0x4079C0C: exit (exit.c:100)
 by 0x40604DA: (below main) (libc-start.c:258)
Address 0x41f2070 is 8 bytes inside a block of size 10 alloc'd
 at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
 by 0x80485AF: GlobalClass::~GlobalClass() (main.cpp:26)
 by 0x4079B80: __run_exit_handlers (exit.c:78)
 by 0x4079C0C: exit (exit.c:100)
 by 0x40604DA: (below main) (libc-start.c:258)
靜态類的構造和釋放都在main之外，是以都出現了(below main)的字樣，堆棧的函數名也很好的證明了這兩個過程。這裡我聯想到了另一個問題，就是靜态構造的順序不一定按預期，強烈建議靜态對象之間不要有依賴關系。

崩潰

如果在memcheck運作你的程式過程中遇到崩潰，它依然能夠提供一些有用的資訊

--16198-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--16198-- si_code=1;  Faulting address: 0x74207972;  sp: 0x6564ca5c
valgrind: the 'impossible' happened:
   Killed by fatal signal
==16198==    at 0x380C0AD4: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198==    by 0x380C12C5: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198==    by 0x38040A63: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198==    by 0x38040B36: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198==    by 0x3803EA4B: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198==    by 0x20202E78: ???

sched status:
  running_tid=3

然後報告中依次羅列崩潰時各線程所處的堆棧和線程的運作狀态

Thread 1: status = VgTs_WaitSys
...

Thread 2: status = VgTs_WaitSys
...

Thread 3: status = VgTs_Runnable
==16198==    at 0x402C9B4: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==16198==    by 0x437D7D3: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16)
==16198==    by 0x437FBB5: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16)
==16198==    by 0x82A76A3: DataChecker::handle_data_check_resp_msg(void*) (data_checker.c:55)
==16198==    by 0x8144411: main_thread(void*) (main_thread.c:198)
==16198==    by 0x82839CF: thread_manager_start_routine(void*) (thread_manager.c:72)
==16198==    by 0x42D3D4B: start_thread (pthread_create.c:308)
==16198==    by 0x450BFDD: clone (clone.S:130)

Thread 4: status = VgTs_WaitSys
...

那麼，運作中的線程自然是嫌疑最大的，我們可以提取它的堆棧資訊做進一步分析。

c++ 坑 think memcheck Valgrind 記憶體洩露 崩潰堆棧
上一篇: java列印記憶體數_如何列印java對象的記憶體使用情況
下一篇: JAVA多線程執行的困惑

繼續閱讀