Linux記憶體越界檢測方法——valgrind__Linux

Linux記憶體越界檢測方法——valgrind

一．Valgrind

1.下載安裝

下載地址：http://valgrind.org/downloads/current.html#current

#configure

#make

#make install

2.使用

2.1內在越界

寫一段有記憶體訪問越界的代碼，如下：

#include <stdio.h>

#include <stdlib.h> 

#include <errno.h>

 

int main() 

{

    char *p = NULL;

    char *temp = NULL;

    

    p = (char*)malloc(sizeof(char));

 

    if (NULL == p) 

    {

        perror("Cannot allocate memory.");

        return -1;

    }

    

    temp[0] = p[6];

 

    free(p);

    p = NULL;

    return 0;

}

儲存檔案test.c

在上面的代碼中，我們給p分配了一個位元組的空間，後面卻要訪問p[6]，看看會出現什麼情況。

2.1.1帶DEBUG編譯

#gcc t-g test.c -o test

2.1.2運行分析

首先直接運行

#./test

段錯誤 (core dumped)

直接報錯退出。

使用valgrind載入運行test

#valgrind --tool=memcheck --leak-check=full ./test

==17686== Memcheck, a memory error detector

==17686== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.

==17686== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info

==17686== Command: ./test

==17686== 

==17686== Invalid read of size 1

==17686==    at 0x40059A: main (test.c:19)

==17686==  Address 0x4c22046 is 5 bytes after a block of size 1 alloc'd

==17686==    at 0x4A0720A: malloc (vg_replace_malloc.c:296)

==17686==    by 0x400575: main (test.c:10)

==17686== 

==17686== Invalid write of size 1

==17686==    at 0x4005A1: main (test.c:19)

==17686==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

==17686== 

==17686== 

==17686== Process terminating with default action of signal 11 (SIGSEGV)

==17686==  Access not within mapped region at address 0x0

==17686==    at 0x4005A1: main (test.c:19)

==17686==  If you believe this happened as a result of a stack

==17686==  overflow in your program's main thread (unlikely but

==17686==  possible), you can try to increase the size of the

==17686==  main thread stack using the --main-stacksize= flag.

==17686==  The main thread stack size used in this run was 10485760.

==17686== 

==17686== HEAP SUMMARY:

==17686==     in use at exit: 1 bytes in 1 blocks

==17686==   total heap usage: 1 allocs, 0 frees, 1 bytes allocated

==17686== 

==17686== LEAK SUMMARY:

==17686==    definitely lost: 0 bytes in 0 blocks

==17686==    indirectly lost: 0 bytes in 0 blocks

==17686==      possibly lost: 0 bytes in 0 blocks

==17686==    still reachable: 1 bytes in 1 blocks

==17686==         suppressed: 0 bytes in 0 blocks

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

==17686== To see them, rerun with: --leak-check=full --show-leak-kinds=all

==17686== 

==17686== For counts of detected and suppressed errors, rerun with: -v

==17686== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)

段錯誤 (core dumped)

 

我們看到，valgrind共報了兩個錯誤，見上面紅色部分，我們分別分析一下：

==17686== Invalid read of size 1

==17686==    at 0x40059A: main (test.c:19)

==17686==  Address 0x4c22046 is 5 bytes after a block of size 1 alloc'd

==17686==    at 0x4A0720A: malloc (vg_replace_malloc.c:296)

==17686==    by 0x400575: main (test.c:10)

這個是讀錯誤，指出在test.c的第19行，在第10行（p = (char*)malloc(sizeof(char));）正常分配給地址（0x4A0720A）1個位元組，讀的地址（0x4c22046）卻是之後的5個位元組處（我們訪問的p[6]）。

 

再分析第二個錯誤：

==17686== Invalid write of size 1

==17686==    at 0x4005A1: main (test.c:19)

==17686==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Valgrind報怨我們沒有分配就開始使用，說的應該是temp了。

2.2記憶體泄露

2.2.1代碼修改

對於記憶體泄露，valgrind也可以很好地檢查出來，在上例中，做如下修改：

#include <stdio.h>

#include <stdlib.h> 

#include <errno.h>

 

int main() 

{

    char *p = NULL;

    char *temp = NULL;

    

    p = (char*)malloc(sizeof(char));

 

    if (NULL == p) 

    {

        perror("Cannot allocate memory.");

        return -1;

    }

    

    

    //temp[0] = p[6];

 

    

    //free(p);

    p = NULL;

   

 

    return 0;

}

注釋記憶體訪問越界和釋放記憶體的代碼。

2.2.2編譯並運行