Valgrind 內存管理檢測工具

時間 2019-12-05

標籤 valgrind 內存管理檢測工具简体版

原文原文鏈接

用C/C++開發其中最使人頭疼的一個問題就是內存管理，有時候爲了查找一個內存泄漏或者一個內存訪問越界，須要要花上好幾天時間，若是有一款工具可以幫助咱們作這件事情就行了，valgrind正好就是這樣的一款工具。 linux

Valgrind是一款基於模擬linux下的程序調試器和剖析器的軟件套件，能夠運行於x86, amd64和ppc32架構上。valgrind包含一個核心，它提供一個虛擬的CPU運行程序，還有一系列的工具，它們完成調試，剖析和一些相似的任務。valgrind是高度模塊化的，因此開發人員或者用戶能夠給它添加新的工具而不會損壞己有的結構。多線程

valgrind的官方網址是：http://valgrind.org 架構

你能夠在它的網站上下載到最新的valgrind，它是開放源碼和免費的。模塊化

1、介紹 函數

valgrind包含幾個標準的工具，它們是：工具

一、memcheck 優化

memcheck探測程序中內存管理存在的問題。它檢查全部對內存的讀/寫操做，並截取全部的malloc/new/free/delete調用。所以memcheck工具可以探測到如下問題：網站

1）使用未初始化的內存 spa

2）讀/寫已經被釋放的內存線程

3）讀/寫內存越界

4）讀/寫不恰當的內存棧空間

5）內存泄漏

6）使用malloc/new/new[]和free/delete/delete[]不匹配。

二、cachegrind

cachegrind是一個cache剖析器。它模擬執行CPU中的L1, D1和L2 cache，所以它能很精確的指出代碼中的cache未命中。若是你須要，它能夠打印出cache未命中的次數，內存引用和發生cache未命中的每一行代碼，每個函數，每個模塊和整個程序的摘要。若是你要求更細緻的信息，它能夠打印出每一行機器碼的未命中次數。在x86和amd64上，cachegrind經過CPUID自動探測機器的cache配置，因此在多數狀況下它再也不須要更多的配置信息了。

三、helgrind

helgrind查找多線程程序中的競爭數據。helgrind查找內存地址，那些被多於一條線程訪問的內存地址，可是沒有使用一致的鎖就會被查出。這表示這些地址在多線程間訪問的時候沒有進行同步，極可能會引發很難查找的時序問題。

2、valgrind對你的程序都作了些什麼

valgrind被設計成非侵入式的，它直接工做於可執行文件上，所以在檢查前不須要從新編譯、鏈接和修改你的程序。要檢查一個程序很簡單，只須要執行下面的命令就能夠了

valgrind --tool=tool_name program_name

好比咱們要對ls -l命令作內存檢查，只須要執行下面的命令就能夠了

valgrind --tool=memcheck ls -l

不論是使用哪一個工具，valgrind在開始以前總會先取得對你的程序的控制權，從可執行關聯庫裏讀取調試信息。而後在valgrind核心提供的虛擬CPU上運行程序，valgrind會根據選擇的工具來處理代碼，該工具會向代碼中加入檢測代碼，並把這些代碼做爲最終代碼返回給valgrind核心，最後valgrind核心運行這些代碼。

若是要檢查內存泄漏，只須要增長--leak-check=yes就能夠了，命令以下

valgrind --tool=memcheck --leak-check=yes ls -l

不一樣工具間加入的代碼變化很是的大。在每一個做用域的末尾，memcheck加入代碼檢查每一片內存的訪問和進行值計算，代碼大小至少增長12倍，運行速度要比平時慢25到50倍。

valgrind模擬程序中的每一條指令執行，所以，檢查工具和剖析工具不只僅是對你的應用程序，還有對共享庫，GNU C庫，X的客戶端庫都起做用。

3、如今開始

首先，在編譯程序的時候打開調試模式（gcc編譯器的-g選項）。若是沒有調試信息，即便最好的valgrind工具也將中可以猜想特定的代碼是屬於哪個函數。打開調試選項進行編譯後再用valgrind檢查，valgrind將會給你的個詳細的報告，好比哪一行代碼出現了內存泄漏。

當檢查的是C++程序的時候，還應該考慮另外一個選項 -fno-inline。它使得函數調用鏈很清晰，這樣能夠減小你在瀏覽大型C++程序時的混亂。好比在使用這個選項的時候，用memcheck檢查openoffice就很容易。固然，你可能不會作這項工做，可是使用這一選項使得valgrind生成更精確的錯誤報告和減小混亂。

一些編譯優化選項(好比-O2或者更高的優化選項)，可能會使得memcheck提交錯誤的未初始化報告，所以，爲了使得valgrind的報告更精確，在編譯的時候最好不要使用優化選項。

若是程序是經過腳本啓動的，能夠修改腳本里啓動程序的代碼，或者使用--trace-children=yes選項來運行腳本。

下面是用memcheck檢查ls -l命令的輸出報告，在終端下執行下面的命令

valgrind --tool=memcheck ls -l

程序會打印出ls -l命令的結果，最後是valgrind的檢查報告以下：

==4187==

==4187== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 2)

==4187== malloc/free: in use at exit: 15,154 bytes in 105 blocks.

==4187== malloc/free: 310 allocs, 205 frees, 60,093 bytes allocated.

==4187== For counts of detected errors, rerun with: -v

==4187== searching for pointers to 105 not-freed blocks.

==4187== checked 145,292 bytes.

==4187==

==4187== LEAK SUMMARY:

==4187== definitely lost: 0 bytes in 0 blocks.

==4187== possibly lost: 0 bytes in 0 blocks.

==4187== still reachable: 15,154 bytes in 105 blocks.

==4187== suppressed: 0 bytes in 0 blocks.

==4187== Reachable blocks (those to which a pointer was found) are not shown.

==4187== To see them, rerun with: --show-reachable=yes

這裏的「4187」指的是執行ls -l的進程ID，這有利於區別不一樣進程的報告。memcheck會給出報告，分配置和釋放了多少內存，有多少內存泄漏了，還有多少內存的訪問是可達的，檢查了多少字節的內存。

下面舉兩個用valgrind作內存檢查的例子

例子一 (test.c)：

#include <string.h>

int main(int argc, char *argv[])
{
    char *ptr;

    ptr = (char*) malloc(10);
    strcpy(ptr, "01234567890");

    return 0;
}

編譯程序

gcc -g -o test test.c

用valgrind執行命令

valgrind --tool=memcheck --leak-check=yes ./test

報告以下

==4270== Memcheck, a memory error detector.

==4270== Using LibVEX rev 1606, a library for dynamic binary translation.

==4270== Using valgrind-3.2.0, a dynamic binary instrumentation framework.

==4270== For more details, rerun with: -v

==4270==

==4270== Invalid write of size 1

==4270== at 0x4006190: strcpy (mc_replace_strmem.c:271)

==4270== by 0x80483DB: main (test.c:8)

==4270== Address 0x4023032 is 0 bytes after a block of size 10 alloc'd

==4270== at 0x40044F6: malloc (vg_replace_malloc.c:149)

==4270== by 0x80483C5: main (test.c:7)

==4270==

==4270== Invalid write of size 1

==4270== at 0x400619C: strcpy (mc_replace_strmem.c:271)

==4270== by 0x80483DB: main (test.c:8)

==4270== Address 0x4023033 is 1 bytes after a block of size 10 alloc'd

==4270== at 0x40044F6: malloc (vg_replace_malloc.c:149)

==4270== by 0x80483C5: main (test.c:7)

==4270==

==4270== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 12 from 1)

==4270== malloc/free: in use at exit: 10 bytes in 1 blocks.

==4270== malloc/free: 1 allocs, 0 frees, 10 bytes allocated.

==4270== For counts of detected errors, rerun with: -v

==4270== searching for pointers to 1 not-freed blocks.

==4270== checked 51,496 bytes.

==4270==

==4270== 10 bytes in 1 blocks are definitely lost in loss record 1 of 1

==4270== at 0x40044F6: malloc (vg_replace_malloc.c:149)

==4270== by 0x80483C5: main (test.c:7)

==4270==

==4270== LEAK SUMMARY:

==4270== definitely lost: 10 bytes in 1 blocks.

==4270== possibly lost: 0 bytes in 0 blocks.

==4270== still reachable: 0 bytes in 0 blocks.

==4270== suppressed: 0 bytes in 0 blocks.

==4270== Reachable blocks (those to which a pointer was found) are not shown.

==4270== To see them, rerun with: --show-reachable=yes

從這份報告能夠看出，進程號是4270，test.c的第8行寫內存越界了，引發寫內存越界的是strcpy函數，

第7行泄漏了10個字節的內存，引發內存泄漏的是malloc函數。

例子二（test2.c)

#include <stdio.h>

int foo(int x)
{
    if (x < 0) {
        printf("%d ", x);
    }

    return 0;
}

int main(int argc, char *argv[])
{
    int x;
   
    foo(x);

    return 0;
}

編譯程序

gcc -g -o test2 test2.c

用valgrind作內存檢查

valgrind --tool=memcheck ./test2

輸出報告以下

==4285== Memcheck, a memory error detector.

==4285== Using LibVEX rev 1606, a library for dynamic binary translation.

==4285== Using valgrind-3.2.0, a dynamic binary instrumentation framework.

==4285== For more details, rerun with: -v

==4285==

==4285== Conditional jump or move depends on uninitialised value(s)

==4285== at 0x8048372: foo (test2.c:5)