【内存】内存检测工具sanitize[内存泄漏、内存越界] VS valgrind
简介
Sanitizers是谷歌发起的开源工具集，包括了AddressSanitizer, MemorySanitizer, ThreadSanitizer, LeakSanitizer，Sanitizers项目本是LLVM项目的一部分，但GNU也将该系列工具加入到了自家的GCC编译器中。GCC从4.8版本开始支持Address和Thread Sanitizer，4.9版本开始支持Leak Sanitizer和UB Sanitizer，这些都是查找隐藏Bug的利器。
valgrind特点：
这个工具相对简单，对于一些复杂的内存泄露可能无法解析出来而且有一个问题就是只有检测的进程退出后才会输出内存泄露信息。
sanitize特点：
sanitize可以在检测到内存泄露第一时间立刻终止进程，并且它可以深入检测（随应用进程一起编译）。
Github 地址：https://github.com/google/sanitizers
Wiki 地址：https://github.com/google/sanitizers/wiki/AddressSanitizer
参考：
基本使用：https://blog.csdn.net/c_lazy/article/details/80009627
输出信息的详细解释：https://www.jianshu.com/p/3a2df9b7c353
AddressSanitizer（地址消毒剂，简称 ASan） 是谷歌出品的内存检查工具，比 Valgrind 更高效。其由两部组成：
- 编译器 instrumentation 模块
- 提供malloc()/free()替代项的运行时库
gcc 4.8 开始，AddressSanitizer 成为 gcc 的一部分，但不支持符号信息，无法显示出问题的函数和行数。从 4.9 开始，gcc 支持 AddressSanitizer 的所有功能。
安装
Ubuntu 一般不用安装，CentOS 一般需要安装。
如果使用 AddressSanitizer 时报错：
/usr/bin/ld: cannot find /usr/lib64/libasan.so.0.0.0
则需要先安装。Ubuntu 安装命令：
sudo apt-get install libasan0
CentOS 安装命令：
sudo yum install libasan
使用方法
内存越界检测
1，内存访问错误是模糊测试通常能够发现的一类错误，其主要是由于程序对不该进行读写操作的内存进行了操作，从而导致了应用程序的崩溃。
2，实际上并不是所有的内存访问错误都能发生崩溃。
test.c来作为一个例子：
#include
int main()
{
int a[2] = {1, 0};
int b = a[2];
return 0;
} 3，我们可以看出这是一个经典的 off-by-one-error错误（(英语:Off-by-one error,缩写OBOE)是在计数时由于边界条件判断失误导致结果多了一或少了一的错误）：
定义一个有两个元素的数组，访问该数组的元素时需从0开始，因此该数组的两个元素分别为a[0]、a[1]。然后将a[2]赋值给b,但实际上a[2]不是数组的一部分，是个无效的数值。所以b最终就成了一个任意的数值，它只是从堆栈和内存中未被定义的部分中读取了“一些”内存。
4，然而和其他的内存访问错误所不同的是，它并不会造成崩溃，即使是强大的 valgrind 也无法告诉我们具体问题在哪里。而在最新版本的 llvm和gcc中有一款工具却可以发现这种错误，它就是Address Sanitizer (ASan) ，它可以直接在编译的时候进行使用。
不过要注意的是，在使用前我们需要在编译器标志中增加一个参数-fsanitize=address。另外，为了使调试更为轻松，我们还需要增加 -ggdb.
zhangsan@PC:~$ gcc -fsanitize=address -ggdb -o test test.c现在，我们再去运行之前的那个例子，我们会得到一个彩色的错误信息：
==7402==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff2971ab88 at pc 0x400904 bp 0x7fff2971ab40 sp 0x7fff2971ab30READ of size 4 at 0x7fff2971ab88 thread T0
#0 0x400903 in main /tmp/test.c:5
#1 0x7fd7e2601f9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f)
#2 0x400778 (/tmp/a.out+0x400778)
Address 0x7fff2971ab88 is located in stack of thread T0 at offset 40 in frame
#0 0x400855 in main /tmp/test.c:1
This frame has 1 object(s):
[32, 40) 'a' <== Memory access at offset 40 overflows 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-buffer-overflow /tmp/test.c:3 main5，我选择了其中最为有趣的一部分，相信这部分已经完全足够说明发生了什么——测试代码的第三行中由于一个大小为4的无效读取导致出现了栈溢出（一个整数的大小）。
使用Address Sanitizer进行软件开发
1，我们在进行模糊测试时，通常对象不会是一个简单的C文件，因此我们必须要把address sanitizer添加到编译器的标志寄存器中。而软件所使用的正常配置脚本则如下所示：
-
zhangsan@PC:~$ ./configure --disable-shared CFLAGS="-fsanitize=address -ggdb" CXXFLAGS="-fsanitize=address -ggdb" -
zhangsan@PC:~$ make
2，为了获得更多的调试信息，我们需要再一次的添加-ggdb。如果可能的话我们还可以禁用共享库并设置C和C++编译器的标志。
3，然后，我们就可以像第一部分所说的那样对运行中的软件进行畸形输入了。而当我们将输出重定向到日志文件时，我们就不得不考虑到我们不能够对分段错误进行grep，而是需要我们去grep Address Sanitizer的消息：
grep AddressSanitizer fuzzing.log在使用Address Sanitizer时，我们还必须要考虑到一些事：
1、ASan发现内存访问违规的时，应用程序并不会自动崩溃。这是由于在使用模糊测试工具时，它们通常都是通过检查返回码来检测这种错误。当然，我们也可以在模糊测试进行之前通过将环境变量 ASAN_OPTIONS修改成如下形式来迫使软件崩溃：
export ASAN_OPTIONS='abort_on_error=1'/2、 ASan需要相当大的虚拟内存（大约20TB），不用担心，这个只是虚拟内存，你仍可以使用你的应用程序。但像 american fuzzy lop这样的模糊测试工具就会对模糊化的软件使用内存进行限制，不过你仍可以通过禁用内存限制来解决该问题。唯一需要注意的就是，这会带来一些风险：测试样本可能会导致应用程序分配大量的内存进而导致系统不稳定或者其他应用程序崩溃。因此在进行一些重要的模糊测试时，不要去尝试在同一个系统上禁用内存限制。
3、 Zzuf目前并不能和 ASan协同工作， 但你仍可以使用zzuf手动去创建一些测试样本将他们输入ASan的编译软件中。
4、还有就是，ASan会显著的延缓执行，其所发现的bug往往没有那么严重（当然也有例外），不过它能发现更多的bug是毋庸置疑的。
Address Sanitizer 用法
RonZheng2010关注
0.6372019.02.01 19:29:33字数 1,451阅读 17,975
Address Sanitizer（ASan）是一个快速的内存错误检测工具。这里说明它的用法。
参考资料
AddressSanitizer
https://github.com/google/sanitizers/wiki/AddressSanitizer
1. 简介
Address Sanitizer（ASan）是一个快速的内存错误检测工具。它非常快，只拖慢程序两倍左右（比起Valgrind快多了）。它包括一个编译器instrumentation模块和一个提供malloc()/free()替代项的运行时库。
从gcc 4.8开始，AddressSanitizer成为gcc的一部分。当然，要获得更好的体验，最好使用4.9及以上版本，因为gcc 4.8的AddressSanitizer还不完善，最大的缺点是没有符号信息。
2. 使用步骤
- 用-fsanitize=address选项编译和链接你的程序。
- 用-fno-omit-frame-pointer编译，以得到更容易理解stack trace。
- 可选择-O1或者更高的优化级别编译
gcc -fsanitize=address -fno-omit-frame-pointer -O1 -g use-after-free.c -o use-after-free
运行use-after-fee。如果发现了错误，就会打印出类似下面的信息：
==9901==ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dfb5
at pc 0x45917b bp 0x7fff4490c700 sp 0x7fff4490c6f8
READ of size 1 at 0x60700000dfb5 thread T0
#0 0x45917a in main use-after-free.c:5
#1 0x7fce9f25e76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
#2 0x459074 in _start (a.out+0x459074)
0x60700000dfb5 is located 5 bytes inside of 80-byte region [0x60700000dfb0,0x60700000e000)
freed by thread T0 here:
#0 0x4441ee in __interceptor_free projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x45914a in main use-after-free.c:4
#2 0x7fce9f25e76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
previously allocated by thread T0 here:
#0 0x44436e in __interceptor_malloc projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
#1 0x45913f in main use-after-free.c:3
#2 0x7fce9f25e76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
SUMMARY: AddressSanitizer: heap-use-after-free use-after-free.c:5 main
- 第一部分（ERROR）指出错误类型是heap-use-after-free；
- 第二部分（READ）, 指出线程名thread T0，操作为READ，发生的位置是use-after-free.c:5。
- 该heapk块之前已经在use-after-free.c:4被释放了；
- 该heap块是在use-fater-free.c:3分配
- 第三部分 (SUMMARY) 前面输出的概要说明。
3. 错误类型
3.1 (heap) use after free 释放后使用
下面的代码中，分配array数组并释放，然后返回它的一个元素。
5 int main (int argc, char** argv)
6 {
7 int* array = new int[100];
8 delete []array;
9 return array[1];
10 }
下面的错误信息与前面的“使用步骤”一节中的类似。
==3189==ERROR: AddressSanitizer: heap-use-after-free on address 0x61400000fe44
at pc 0x0000004008f1 bp 0x7ffc9b6e2630 sp 0x7ffc9b6e2620
READ of size 4 at 0x61400000fe44 thread T0
#0 0x4008f0 in main /home/ron/dev/as/use_after_free.cpp:9
#1 0x7f3763aa882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#2 0x4007b8 in _start (/home/ron/dev/as/build/use_after_free+0x4007b8)
0x61400000fe44 is located 4 bytes inside of 400-byte region [0x61400000fe40,0x61400000ffd0)
freed by thread T0 here:
#0 0x7f3763ef1caa in operator delete[](void*) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99caa)
#1 0x4008b5 in main /home/ron/dev/as/use_after_free.cpp:8
#2 0x7f3763aa882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
previously allocated by thread T0 here:
#0 0x7f3763ef16b2 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x996b2)
#1 0x40089e in main /home/ron/dev/as/use_after_free.cpp:7
#2 0x7f3763aa882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
SUMMARY: AddressSanitizer: heap-use-after-free /home/ron/dev/as/use_after_free.cpp:9 main
3.2 heap buffer overflow 堆缓存访问溢出
如下代码中，访问的位置超出堆上数组array的边界。
2 int main (int argc, char** argv)
3 {
4 int* array = new int[100];
5 int res = array[100];
6 delete [] array;
7 return res;
8 }
下面的错误信息指出：
- 错误类型是heap-buffer-overflow
- 不合法操作READ发生在线程T0, heap_buf_overflow.cpp:5
- heap块分配发生在heap_buf_overflow.cpp
==3322==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61400000ffd0
at pc 0x0000004008e0 bp 0x7ffeddce53a0 sp 0x7ffeddce5390
READ of size 4 at 0x61400000ffd0 thread T0
#0 0x4008df in main /home/ron/dev/as/heap_buf_overflow.cpp:5
#1 0x7f3b83d0882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#2 0x4007b8 in _start (/home/ron/dev/as/build/heap_buf_overflow+0x4007b8)
0x61400000ffd0 is located 0 bytes to the right of 400-byte region [0x61400000fe40,0x61400000ffd0)
allocated by thread T0 here:
#0 0x7f3b841516b2 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x996b2)
#1 0x40089e in main /home/ron/dev/as/heap_buf_overflow.cpp:4
#2 0x7f3b83d0882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ron/dev/as/heap_buf_overflow.cpp:5 main
3.2 stack buffer overflow 栈缓存访问溢出
如下代码中，访问的位置超出栈上数组array的边界。
2 int main (int argc, char** argv)
3 {
4 int array[100];
5 return array[100];
6 }
下面的错误信息指出：
- 错误类型是stack-buffer-overflow
- 不合法操作READ发生在线程T0, stack_buf_overflow.cpp:5
- 栈块在线程T0的栈上432偏移位置上。
==3389==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd061fa4a0
at pc 0x0000004009ff bp 0x7ffd061fa2d0 sp 0x7ffd061fa2c0
READ of size 4 at 0x7ffd061fa4a0 thread T0
#0 0x4009fe in main /home/ron/dev/as/stack_buf_overflow.cpp:5
#1 0x7fbade4e882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#2 0x400858 in _start (/home/ron/dev/as/build/stack_buf_overflow+0x400858)
Address 0x7ffd061fa4a0 is located in stack of thread T0 at offset 432 in frame
#0 0x400935 in main /home/ron/dev/as/stack_buf_overflow.cpp:3
This frame has 1 object(s):
[32, 432) 'array' <== Memory access at offset 432 overflows 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-buffer-overflow /home/ron/dev/as/stack_buf_overflow.cpp:5 main
3.3 global buffer overflow 全局缓冲访问溢出
如下代码中，访问的位置超出全局数组array的边界。
2 int array[100];
3
4 int main (int argc, char** argv)
5 {
6 return array[100];
7 }
下面的错误信息指出：
- 错误类型是global-buffer-overflow
- 不合法操作READ发生在线程T0, global_buf_overflow.cpp:6
- 缓存块在global_buf_overflow.cpp:2 定义。
==3499==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000601270
at pc 0x000000400915 bp 0x7ffd8e80c020 sp 0x7ffd8e80c010
READ of size 4 at 0x000000601270 thread T0
#0 0x400914 in main /home/ron/dev/as/global_buf_overflow.cpp:6
#1 0x7f613c1c882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#2 0x400808 in _start (/home/ron/dev/as/build/global_buf_overflow+0x400808)
0x000000601270 is located 0 bytes to the right of global variable 'array' defined in
'/home/ron/dev/as/global_buf_overflow.cpp:2:5' (0x6010e0) of size 400
SUMMARY: AddressSanitizer: global-buffer-overflow /home/ron/dev/as/global_buf_overflow.cpp:6 main
3.4 use after return
3.5 use after scope
3.6 initializations order bugs
3.7 memory leaks 内存泄露
检测内存的LeakSanitizer是集成在AddressSanitizer中的一个相对独立的工具，它工作在检查过程的最后阶段。
下面代码中，p指向的内存没有释放。
4 void* p;
5
6 int main ()
7 {
8 p = malloc (7);
9 p = 0;
10 return 0;
11 }
下面的错误信息指出 detected memory leaks
- 内存在mem_leak.cpp:8分配
- 缓存块在global_buf_overflow.cpp:2 定义。
==4088==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x7ff9ae510602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x4008d3 in main /home/ron/dev/as/mem_leak.cpp:8
#2 0x7ff9ae0c882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
目前，并不是所有的平台都默认检测内存泄露，可以指定ASAN_OPTIONS开启如下：
ASAN_OPTIONS=detect_leaks=1 yourapp
而且不是所有的平台支持检测内存泄露，比如ARM，就会得到这样的提示：
==1901==AddressSanitizer: detect_leaks is not supported on this platform.
4. 工作原理
4.1 概要说明
AddressSanitizer的运行时库替换malloc()/free()。分配缓存前后的空间标记为poisoned，已经被释放的缓存也被标记为poisoned。内存访问的代码都被编译器替换如下：
替换之前：
*address = ...;
替换之后：
if (IsPoisoned(address))
{
ReportError(address, kAccessSize, kIsWrite);
}
*address = ...;
访问之前检查访问地址是否poisoned，如果是，报告错误。
4.2 memory mapping 和 instrumentation
进程的虚拟地址空间划分为两个不相连的部分：
- main application memory (Mem)。这是程序自身代码使用的内存；
- Shadow memory (Shadow)。这里放的是shadow value（meta data）。从Mem到Shadow之间有映射关系。将Mem的一个字节标记为poisoned，其实就是在对应的Shadow内存中写入指定值。
伪代码如下。它先从Mem中地址计算对应的Shadow地址。
shadow_address = MemToShadow (address);
if (ShadowIsPoisoned(shadow_address))
{
ReportError (address, kAccessSize, kIsWrite);
}
4.3 mapping
Mem中的8字节映射到Shadow memory中是1字节。
这个字节可能有9种不同的值：
- 所有8字节都是unpoisoned的，则值为0；
- 所有8字节都是poisoned的，则值为负；
- 前k字节为unpoisoned，后面8-k字节为poisoned， 则值为k。
- malloc()分配的内存总是8字节的倍数，如果要分配的缓存不是8字节的倍数，则尾部的8个字节poisoned状态不同。比如分配13字节，会得到两个8字节。前1个全是unpoisoned，后一个只有前5个字节是unpoisoned，后3个字节是poisoned。
4.4 栈的处理
为了捕捉栈的访问溢出，AddressSanitizer在缓存前后加上保护区。这里可以看到设置对应Shadow memory的代码。
改编之前为：
void foo()
{
char a[8];
...
return;
}
改编之后为：
void foo()
{
char redzone1[32]; // 32-byte aligned
char a[8]; // 32-byte aligned
char redzone2[24];
char redzone3[32]; // 32-byte aligned
int *shadow_base = MemToShadow(redzone1);
shadow_base[0] = 0xffffffff; // poison redzone1
shadow_base[1] = 0xffffff00; // poison redzone2, unpoison 'a'
shadow_base[2] = 0xffffffff; // poison redzone3
...
shadow_base[0] = shadow_base[1] = shadow_base[2] = 0; // unpoison all
return;
}
4.5 malloc()/free()的处理
运行时库用自己的函数替换malloc() / free()。
- malloc()在缓存前后分配保护区。缓存本身标记为unpoisoned，保护区标记为poisoned。
- free() 将整个区域，包括缓存和保护区，都标记为poisoned，并将该区域放入一个特别的队列中，以保证malloc()在相当长的时间内不会再次使用它）。
相关链接
GDB 常用法
GDB 调试Coredump问题
嵌入式开发中GDB调试Coredump问题
嵌入式开发中GDB串口远程调试
用backtrace()调试coredump问题
Valgrind memcheck 用法
Address Sanitizer 用法
LeakSanitizer （配合AddressSanitizer）
以前用过valgrind这个内存泄露检查工具，这个工具相对简单，对于一些复杂的内存泄露可能无法解析出来而且有一个问题就是只有检测的进程退出后才会输出内存泄露信息。
今天介绍的工具sanitize可以在检测到内存泄露第一时间立刻终止进程，并且它可以深入检测（随应用进程一起编译）。下面举例说明：
#include
#include
extern void __lsan_do_leak_check();
void FooBar()
{
malloc(7);
}
int main()
{
FooBar();
while(1) //死循环
{
__lsan_do_leak_check();
sleep(10);
}
return 0;
}
我这里的编译方式如下：
/opt/gcc-7.3.0/bin/gcc -Wl,-rpath=/opt/gcc-7.3.0/lib64 -fsanitize=leak -llsan a.c
编译参数必须指定 -fsanitize=leak，如果检测非法内存则指定-fsanitize=address。编译完成后运行：
[root@localhost ~]# ./a.out
=================================================================
==11456==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x7f93d7ee8136 in __interceptor_malloc ../../../../libsanitizer/lsan/lsan_interceptors.cc:53
#1 0x400674 in FooBar (/root/a.out+0x400674)
#2 0x400685 in main (/root/a.out+0x400685)
#3 0x7f93d7b303d4 in __libc_start_main (/lib64/libc.so.6+0x223d4)
SUMMARY: LeakSanitizer: 7 byte(s) leaked in 1 allocation(s).
[root@localhost ~]#
如上图所示，能够将堆栈信息打印出来（有些时候打印堆栈信息不全）。如果我们在希望在进程终止时打印内存泄露，那么我们在代码中可以不调用__lsan_do_leak_check();方法。
sanitize还提供了很多参数，可参考https://github.com/google/sanitizers/
原文链接：https://blog.csdn.net/xxb249/article/details/90764921