Linux如何調(diào)試內(nèi)存泄漏
內(nèi)存泄漏是指由于疏忽或錯(cuò)誤造成程序未能釋放已經(jīng)不再使用的內(nèi)存。內(nèi)存泄漏并非指內(nèi)存在物理上的消失,而是應(yīng)用程序分配某段內(nèi)存后,由于設(shè)計(jì)錯(cuò)誤,導(dǎo)致在釋放該段內(nèi)存之前就失去了對(duì)該段內(nèi)存的控制,從而造成了內(nèi)存的浪費(fèi)。
我們平時(shí)開(kāi)發(fā)過(guò)程中不可避免的會(huì)遇到內(nèi)存泄漏問(wèn)題,你是如何排查的呢?估計(jì)你是使用下面這幾個(gè)工具吧?
valgrind
mtrace
dmalloc
ccmalloc
memwatch
debug_new
這里程序喵向大家推薦新的一個(gè)排查內(nèi)存泄漏的工具:AddressSanitizer(ASan),該工具為gcc自帶,4.8以上版本都可以使用,支持Linux、OS、Android等多種平臺(tái),不止可以檢測(cè)內(nèi)存泄漏,它其實(shí)是一個(gè)內(nèi)存錯(cuò)誤檢測(cè)工具,可以檢測(cè)的問(wèn)題有:
內(nèi)存泄漏
堆棧和全局內(nèi)存越界訪問(wèn)
free后繼續(xù)使用
局部?jī)?nèi)存被外層使用
Initialization order bugs(中文不知道怎么翻譯才好,后面有代碼舉例,重要)
使用方法直接看我下面的代碼:
檢測(cè)內(nèi)存泄漏
內(nèi)存泄漏代碼:
void func1() { malloc(7); }
void func2() { malloc(5); }
int main() {
func1();
func2();
return 0;
}
編譯and輸出:
g++ -fsanitize=address -g test_leak.cc && ./a.out
=================================================================
==103==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) 0 0x7f95b231eb40
in func1() /home/wangzhiqiang/test/test_leak.cc:3 1 0x7f95b36007f7
in main /home/wangzhiqiang/test/test_leak.cc:8 2 0x7f95b3600814
in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) 3 0x7f95b1e61b96
Direct leak of 5 byte(s) in 1 object(s) allocated from:
in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) 0 0x7f95b231eb40
in func2() /home/wangzhiqiang/test/test_leak.cc:5 1 0x7f95b3600808
in main /home/wangzhiqiang/test/test_leak.cc:9 2 0x7f95b3600819
in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) 3 0x7f95b1e61b96
SUMMARY: AddressSanitizer: 12 byte(s) leaked in 2 allocation(s).
編譯方式很簡(jiǎn)單,只需要添加-fsanitize=address -g就可以檢測(cè)出具體產(chǎn)生內(nèi)存泄漏的位置以及泄漏空間的大小。
檢測(cè)堆棧內(nèi)存越界訪問(wèn)
示例:
int main() {
int *array = new int[100];
array[0] = 0;
int res = array[100]; // out of bounds
delete[] array;
return res;
}
編譯and輸出:
g++ -fsanitize=address -g test_leak.cc && ./a.out
=================================================================
==110==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6140000001d0 at pc 0x7f0e06400d2e bp 0x7ffff5963f10 sp 0x7ffff5963f00
READ of size 4 at 0x6140000001d0 thread T0
#0 0x7f0e06400d2d in main /home/wangzhiqiang/test/test_leak.cc:6
#1 0x7f0e048d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#2 0x7f0e06400bb9 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xbb9)
0x6140000001d0 is located 0 bytes to the right of 400-byte region [0x614000000040,0x6140000001d0)
allocated by thread T0 here:
#0 0x7f0e05120608 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0608)
#1 0x7f0e06400cab in main /home/wangzhiqiang/test/test_leak.cc:4
#2 0x7f0e048d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wangzhiqiang/test/test_leak.cc:6 in main
Shadow bytes around the buggy address:
0x0c287fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c287fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c287fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c287fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c287fff8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c287fff8030: 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa
0x0c287fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c287fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c287fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c287fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c287fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==110==ABORTING
可以方便定位到堆棧內(nèi)存越界訪問(wèn)的錯(cuò)誤。
全局內(nèi)存越界訪問(wèn):
示例:
int global_array[100] = {0};
int main() {
int res = global_array[100]; // out of bounds
return 0;
}
編譯and輸出:
g++ -fsanitize=address -g test_leak.cc && ./a.out
=================================================================
==116==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f42e6e02310 at pc 0x7f42e6c00c84 bp 0x7fffdda52780 sp 0x7fffdda52770
READ of size 4 at 0x7f42e6e02310 thread T0
#0 0x7f42e6c00c83 in main /home/wangzhiqiang/test/test_leak.cc:6
#1 0x7f42e50d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#2 0x7f42e6c00b69 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb69)
0x7f42e6e02310 is located 0 bytes to the right of global variable 'global_array' defined in 'test_leak.cc:3:5' (0x7f42e6e02180) of size 400
SUMMARY: AddressSanitizer: global-buffer-overflow /home/wangzhiqiang/test/test_leak.cc:6 in main
Shadow bytes around the buggy address:
0x0fe8dcdb8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe8dcdb8420: 00 00 00 00 00 00 00 00 01 f9 f9 f9 f9 f9 f9 f9
0x0fe8dcdb8430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe8dcdb8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe8dcdb8450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fe8dcdb8460: 00 00[f9]f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x0fe8dcdb8470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe8dcdb8480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe8dcdb8490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe8dcdb84a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe8dcdb84b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==116==ABORTING
局部?jī)?nèi)存被外層使用
示例:
volatile int *p = 0;
int main() {
{
int x = 0;
p = &x;
}
*p = 5;
return 0;
}
編譯and輸出:
g++ -fsanitize=address -g test_leak.cc && ./a.out
=================================================================
==243==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffce12a4b0 at pc 0x7f3993e00e7e bp 0x7fffce12a480 sp 0x7fffce12a470
WRITE of size 4 at 0x7fffce12a4b0 thread T0
#0 0x7f3993e00e7d in main /home/wangzhiqiang/test/test_leak.cc:10
#1 0x7f39922d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#2 0x7f3993e00c89 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xc89)
Address 0x7fffce12a4b0 is located in stack of thread T0 at offset 32 in frame
#0 0x7f3993e00d79 in main /home/wangzhiqiang/test/test_leak.cc:5
This frame has 1 object(s):
[32, 36) 'x' <== Memory access at offset 32 is inside this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope /home/wangzhiqiang/test/test_leak.cc:10 in main
Shadow bytes around the buggy address:
0x100079c1d440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100079c1d490: 00 00 f1 f1 f1 f1[f8]f2 f2 f2 00 00 00 00 00 00
0x100079c1d4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d4b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d4c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d4d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==243==ABORTING
free后被使用
示例:
int main() {
int *array = new int[100];
delete[] array;
int a = array[0]; // error
return 0;
}
編譯and輸出:
g++ -fsanitize=address -g test_leak.cc && ./a.out
=================================================================
==282==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000000040 at pc 0x7f209fa00caa bp 0x7ffff2a15020 sp 0x7ffff2a15010
READ of size 4 at 0x614000000040 thread T0
#0 0x7f209fa00ca9 in main /home/wangzhiqiang/test/test_leak.cc:6
#1 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#2 0x7f209fa00b69 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb69)
0x614000000040 is located 0 bytes inside of 400-byte region [0x614000000040,0x6140000001d0)
freed by thread T0 here:
#0 0x7f209e721480 in operator delete[](void*) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe1480)
#1 0x7f209fa00c72 in main /home/wangzhiqiang/test/test_leak.cc:5
#2 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
previously allocated by thread T0 here:
#0 0x7f209e720608 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0608)
#1 0x7f209fa00c5b in main /home/wangzhiqiang/test/test_leak.cc:4
#2 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
SUMMARY: AddressSanitizer: heap-use-after-free /home/wangzhiqiang/test/test_leak.cc:6 in main
Shadow bytes around the buggy address:
0x0c287fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c287fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c287fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c287fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c287fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c287fff8000: fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd fd fd
0x0c287fff8010: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c287fff8020: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c287fff8030: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
0x0c287fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c287fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==282==ABORTING
Initialization order bugs
示例,這里有兩個(gè)文件:
// test_memory1.cc
extern int extern_global;
int read_extern_global() { return extern_global; }
int x = read_extern_global() + 1;
int main() {
printf("%d\n", x);
return 0;
}
// test_memory2.cc
int foo() { return 123; }
int extern_global = foo();
第一種編譯方式輸出如下:
g++ test_memory1.cc test_memory2.cc && ./a.out
1
第二種編譯方式輸出如下:
g++ test_memory2.cc test_memory1.cc && ./a.out
124
這種問(wèn)題我們平時(shí)編程過(guò)程中可以都不會(huì)太注意,然而通過(guò)ASan可以檢測(cè)出這種潛在的bug:
編譯and輸出:
g++ -fsanitize=address -g test_memory1.cc test_memory2.cc
ASAN_OPTIONS=check_initialization_order=true:strict_init_order=true ./a.out
=================================================================
==419==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7f46c20021a0 at pc 0x7f46c1e00c28 bp 0x7fffe423d920 sp 0x7fffe423d910
READ of size 4 at 0x7f46c20021a0 thread T0
#0 0x7f46c1e00c27 in read_extern_global() /home/wangzhiqiang/test/test_memory1.cc:3
#1 0x7f46c1e00cb3 in __static_initialization_and_destruction_0 /home/wangzhiqiang/test/test_memory1.cc:4
#2 0x7f46c1e00d0a in _GLOBAL__sub_I__Z18read_extern_globalv /home/wangzhiqiang/test/test_memory1.cc:8
#3 0x7f46c1e00e5c in __libc_csu_init (/mnt/d/wzq/wzq/util/test/a.out+0xe5c)
#4 0x7f46c0461b27 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b27)
#5 0x7f46c1e00b09 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb09)
0x7f46c20021a0 is located 0 bytes inside of global variable 'extern_global' defined in 'test_memory2.cc:2:5' (0x7f46c20021a0) of size 4
registered at:
#0 0x7f46c08764a8 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x364a8)
#1 0x7f46c1e00e0b in _GLOBAL__sub_I_00099_1__Z3foov (/mnt/d/wzq/wzq/util/test/a.out+0xe0b)
#2 0x7f46c1e00e5c in __libc_csu_init (/mnt/d/wzq/wzq/util/test/a.out+0xe5c)
SUMMARY: AddressSanitizer: initialization-order-fiasco /home/wangzhiqiang/test/test_memory1.cc:3 in read_extern_global()
Shadow bytes around the buggy address:
0x0fe9583f83e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe9583f83f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe9583f8400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe9583f8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe9583f8420: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
=>0x0fe9583f8430: 00 00 00 00[f6]f6 f6 f6 f6 f6 f6 f6 00 00 00 00
0x0fe9583f8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe9583f8450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe9583f8460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe9583f8470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe9583f8480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==419==ABORTING
注意:這里在運(yùn)行程序前需要添加環(huán)境變量:
ASAN_OPTIONS=check_initialization_order=true:strict_init_order=true
小總結(jié)
ASan是個(gè)很好的檢測(cè)內(nèi)存問(wèn)題的工具,不需要配置環(huán)境,使用還方便,編譯時(shí)只需要-fsanitize=address -g就可以,運(yùn)行程序時(shí)候可以選擇添加對(duì)應(yīng)的ASAN_OPTIONS環(huán)境變量就可以檢測(cè)出很多內(nèi)存問(wèn)題。它的錯(cuò)誤信息也很有用,明確指出當(dāng)前是什么類型的內(nèi)存錯(cuò)誤,如:
detected memory leaks
heap-buffer-overflow
stack-buffer-overflow
global-buffer-overflow
heap-use-after-free
initialization-order-fiasco
具體可以看google的官方文檔:https://github.com/google/sanitizers/wiki/AddressSanitizer
c++11新特性,所有知識(shí)點(diǎn)都在這了!
內(nèi)存對(duì)齊之格式修訂版
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問(wèn)題,請(qǐng)聯(lián)系我們,謝謝!