建设网站会员百度识图以图搜图
概述
Asan是Google专门为C/C++开发的内存错误探测工具，其具有如下功能
- 使用已释放内存（野指针）√
- 堆内存越界（读写）√
- 栈内存越界（读写）√
- 全局变量越界（读写）×
- 函数返回局部变量 ×
- 内存泄漏 √
注：本文中测试使用的系统为Ubuntu 16.04，GCC版本为5.4.0，上面功能打√表示该版本GCC支持的功能，打×的表示该版本GCC不支持的功能。
Asan 运行十分的快，被测程序的运行速度一般只会降低2倍（相比于valgrind动辄10~20倍的性能下降来说，已经非常快了）。
Asan包括编译器指令模块和运行时库两部分组成：
-
编译器插桩模块
在程序编译时加入控制指令，用于监测程序的所有内存使用行为，代码中每一次的内存访问操作都会被编译器修改如下方式：原始代码：
*address = ...; // or: ... = *address;编译后代码：
if (IsPoisoned(address)) {ReportError(address, kAccessSize, kIsWrite); } *address = ...; // or: ... = *address;
-* 运行时库*
用于替换glibc库的malloc/free函数，实现内存的分配和释放操作。malloc执行完后，已分配内存的前后（称为“红区”）会被标记为“中毒”状态，而释放的内存则会被隔离起来（暂时不会分配出去）且也会被标记为“中毒”状态。
Asan起初作为LLVM的一部分，后来其被集成到了4.8版本的GCC中，其可以运行在X86、ARM、MIPS、PowerPC等平台，操作系统支持Linux、OS X、iOS、Android、FreeBSD。
编译配置
GCC编译选项
-
-fsanitize=address：开启内存越界检测
-
-fsanitize=leak：开启内存泄漏检测
-
-fsanitize-recover=address：一般后台程序为保证稳定性，不能遇到错误就简单退出，而是继续运行，采用该选项支持内存出错之后程序继续运行，需要叠加设置环境变量ASAN_
OPTIONS=halt_on_error=0才会生效；若未设置此选项，则内存出错即报错退出 -
-fno-stack-protector：去使能栈溢出保护
-
-fno-omit-frame-pointer：去使能栈溢出保护
-
-fno-var-tracking：默认选项为-fvar-tracking，会导致运行非常慢
-
-g1：表示最小调试信息，通常debug版本用-g即-g2
在Makefile中可以通过设置类似于下面的编译选项控制GCC的关于Asan的选项。
ASAN_CFLAGS += -fsanitize=address -fsanitize-recover=address
Asan运行选项
ASAN_OPTIONS是Address-Sanitizier的运行选项环境变量。
- halt_on_error=0：检测内存错误后继续运行
- detect_leaks=1:使能内存泄露检测
- malloc_context_size=15：内存错误发生时，显示的调用栈层数为15
- log_path=/var/log/asan.log:内存检查问题日志存放文件路径
- suppressions=$SUPP_FILE:屏蔽打印某些内存错误
下面是设置ASAN_OPTIONS环境变量:
export ASAN_OPTIONS=halt_on_error=0:use_sigaltstack=0:detect_leaks=1:malloc_context_size=15:log_path=/var/log/asan.log:suppressions=$SUPP_FILE
LSAN_OPTIONS是内存泄漏检测模块LeakSanitizier的环境变量，常用的运行选项如下：
-
exitcode=0：设置内存泄露退出码为0，默认情况内存泄露退出码0x16
-
use_unaligned=4：4字节对齐
下面是设置LSAN_OPTIONS环境变量:
export LSAN_OPTIONS=exitcode=0:use_unaligned=4
Asan运行库配置
用于Asan接管了应用程序内存的申请和释放操作，其替换了原有malloc和free的操作，比如glibc库，所以在程序运行前需要使用LD_PRELOAD指定下libasan.so的位置。
示例
Asan除了内存泄漏之外，默认情况下，其监测到内存问题后，程序就会立即退出，并且打印出相关的内存问题日志。对于内存泄漏问题，当程序正常退出时，才会检测程序是否存在内存泄漏，这里说的正常退出，对于C/C++程序有几种情况:
- main函数，return退出
- 调用了exit函数退出
如果进程由于信号而退出的话，Asan不能检测是否存在内存泄漏。
堆访问越界(heap-buffer-overflow)
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char **argv)
{int *array = malloc(sizeof (int) * 100);array[0] = 0;int res = array[1 + 100]; //array访问越界free(array);pause();//程序等待，不退出return 0;
}
编译命令：
gcc heapOOB.c -o heapOOB -g -fsanitize=address -fsanitize=leak
执行情况：
==3653==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61400000ffd4 at pc 0x000000400871 bp 0x7ffe50cde9c0 sp 0x7ffe50cde9b0
READ of size 4 at 0x61400000ffd4 thread T0
#0 0x400870 in main /home/jetpack/work/4G/test/asan/heapOOB.c:7
#1 0x7f30b337a83f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
#2 0x400708 in _start (/home/jetpack/work/4G/test/asan/heapOOB+0x400708)
0x61400000ffd4 is located 4 bytes to the right of 400-byte region [0x61400000fe40,0x61400000ffd0)
allocated by thread T0 here:
#0 0x7f30b37bc602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x4007ee in main /home/jetpack/work/4G/test/asan/heapOOB.c:5
#2 0x7f30b337a83f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
栈访问越界(stack-buffer-overflow)
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char **argv)
{int stack_array[100];stack_array[100] = 0;//栈访问越界pause();return 0;
}
编译命令：
gcc stackOOB.c -o stackOOB -g -fsanitize=address -fsanitize=leak
执行结果：
==3952==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffdb72e830 at pc 0x0000004008ef bp 0x7fffdb72e660 sp 0x7fffdb72e650
WRITE of size 4 at 0x7fffdb72e830 thread T0
#0 0x4008ee in main /home/jetpack/work/4G/test/asan/stackOOB.c:6
#1 0x7f0c47a8e83f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
#2 0x400748 in _start (/home/jetpack/work/4G/test/asan/stackOOB+0x400748)
Address 0x7fffdb72e830 is located in stack of thread T0 at offset 432 in frame
#0 0x400825 in main /home/jetpack/work/4G/test/asan/stackOOB.c:4
This frame has 1 object(s):
[32, 432) 'stack_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)
使用已经释放的内存（UseAfterFree）
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char **argv)
{int *array = malloc(sizeof (int) * 100);array[0] = 0;free(array);int res = array[0]; //使用已经释放的内存pause();return 0;
}
编译命令：
gcc heapUAF.c -o heapUAF -g -fsanitize=address -fsanitize=leak
执行结果:
==4385==ERROR: AddressSanitizer: heap-use-after-free on address 0x61400000fe40 at pc 0x000000400877 bp 0x7ffdc9019c20 sp 0x7ffdc9019c10
READ of size 4 at 0x61400000fe40 thread T0
#0 0x400876 in main /home/jetpack/work/4G/test/asan/heapUAF.c:8
#1 0x7f93f8d5683f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
#2 0x400708 in _start (/home/jetpack/work/4G/test/asan/heapUAF+0x400708)
0x61400000fe40 is located 0 bytes inside of 400-byte region [0x61400000fe40,0x61400000ffd0)
freed by thread T0 here:
#0 0x7f93f91982ca in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x982ca)
#1 0x40083f in main /home/jetpack/work/4G/test/asan/heapUAF.c:7
#2 0x7f93f8d5683f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
previously allocated by thread T0 here:
#0 0x7f93f9198602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x4007ee in main /home/jetpack/work/4G/test/asan/heapUAF.c:5
#2 0x7f93f8d5683f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
内存泄漏 (Memory Leak)
#include <string.h>
#include <stdlib.h>
#include <unistd.h>int main(int argc, char **argv)
{int *array = malloc(sizeof (int) * 100);memset(array, 0, 100 * 4);return 0;
}
编译命令：
gcc heapLeak.c -o heapLeak -g -fsanitize=address -fsanitize=leak
执行结果：
==3120==ERROR: LeakSanitizer: detected memory leaksDirect leak of 400 byte(s) in 1 object(s) allocated from:
#0 0x7f412d5b7602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x40073e in main /home/jetpack/work/4G/test/asan/heapLeak.c:7
#2 0x7f412d17583f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)SUMMARY: AddressSanitizer: 400 byte(s) leaked in 1 allocation(s).实际应用中，特别是嵌入式设备，程序会一直运行，直到程序遇到问题，比如，内存访问越界导致段错误。所以，如果想随时使程序正常退出，检测程序是否存在内存泄漏的话，可以通过向进程发送特定的信号，
进程接收到信号后主动退出程序，从而触发Asan内存泄漏检测。
//heapLeak.c#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <stdio.h>static int is_exit = 0;void sig_exit(int num)
{if (num == SIGUSR1) {//接收到SIGUSR1后，设置is_exit为1printf("SIGKILL\n");is_exit = 1;}
}int main(int argc, char **argv)
{struct sigaction action;sigemptyset(&action.sa_mask);action.sa_flags = 0;action.sa_handler = sig_exit;sigaction(SIGUSR1, &action, NULL);int *array = malloc(sizeof (int) * 100);memset(array, 0, 100 * 4); while(1) { if (is_exit) {//如果is_exit为1，退出循环，从使程序正常退出break;} sleep(1);} return 0;
}
编译命令：
gcc heapLeak.c -o heapLeak -g -fsanitize=address -fsanitize=leak
测试过程，运行heapLeak
./heapLeak //等待接收SIGUSR1
//查询进程id
pidof heapLeak
4347//发送SIGUSR1信号
kill -SIGUSR1 4347
heapLeak收到SIGUSR1之后，退出，并输出内存泄漏统计信息：
==4347==ERROR: LeakSanitizer: detected memory leaksDirect leak of 400 byte(s) in 1 object(s) allocated from:
#0 0x7fbcd578d602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x400b31 in main /home/jetpack/work/4G/test/asan/heapLeak.c:26
#2 0x7fbcd534b83f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)SUMMARY: AddressSanitizer: 400 byte(s) leaked in 1 allocation(s).函数返回的局部变量访问
int *ptr;
void usr_func(void)
{ //申请栈内存int local[100] = {0};ptr = local;
} int main(void)
{ //使用函数栈返回的内存*ptr = 0;return 0;
}
全局变量访问越界
int global_array[100] = {0}; int main(int argc, char **argv)
{//全局变量global_array访问越界 global_array[101];return 0;
}注：全局变量访问越界(GlobalOutOfBounds)和函数返回的局部变量访问（UseAfterReturn），gcc-5.4.0暂时不支持，所以暂时不能测试。
日志记录内存问题
如果出现问题时，不是直接退出程序，而是继续运行，并且把内存问题输出到文件中的话，可以通过使用-fsanitize-recover=address编译选项，配合ASAN_OPTIONS变量实现，运行程序之前声明该变量即可。
编译时，加上-fsanitize-recover=address选项:
gcc heapOOB.c -o heapOOB -g -fsanitize=address -fsanitize=leak -fsanitize-recover=address运行时，先声明ASAN_OPTIONS再运行程序：
export ASAN_OPTIONS=halt_on_error=0:use_sigaltstack=0:detect_leaks=1:malloc_context_size=15:log_path=/var/log/asan.log:suppressions=$SUPP_FILE
如果gcc不支持-fsanitize-recover=address编译选项，比如，我现在使用的gcc-5.4.0，那么程序在遇到问题的时候，还是自动退出，但，日志会输出到log_path指定的目录，比如
asan.log.5089 asan.log.5090 asan.log.5348 //其中，文件后面的数字表示程序的进程号
番外篇
说一个最近使用Asan的经历，过程比较心酸，但是，也许有些意义，拿来和大家分享下。
其实，之前我是从来没有用Asan的，某天看到后，觉得这厮功能十分的强大，可以拿来玩玩。于是，写了个几个常见的内存使用问题，发现确实可以在第一时间就能把问题揪出来。正巧我当时，正在做一个嵌入式Linux的项目，程序规模属于中等，基本功能当时开发完了，想着正好可以使用Asan测试下这个项目是不是存在内存问题。记得当时还查阅了一些资料，分析了如何在项目里面使用Asan。之后，就把Asan用上了，当时确实找出来一个错误，然后，就没有再出现啥问题了(现在想想，当时最大的疏忽就是没有看使用Asan工具会给应用带来多大额外的内存耗损，就不会后来一直冤枉人家应用程序存在内存泄漏了;))。
这样相安无事的过了一段时间后，有一天在我发现系统的内存剩余很少了，第一反应就是应用出现了内存泄漏，通过长时间的监测，确定应用程序内存使用量存在不断增长的问题，进一步印证了内存泄漏的猜想。之后通过各种分析，甚至使用了valgrind工具，都没有检测到内存泄漏，但，应用内存使用量确实在不断增长，最后搞的十分的郁闷。
后来，网络上有说，glibc自带的内存分配器（ptmalloc）存在问题，很容易造成内存碎片，导致很多内存即使被free了，也只能被进程占着，不能返还给OS。我觉得，这不是正和我遇到的问题一样嘛，于是乎，我查阅了大量的资料，学习glibc ptmalloc的实现机制，以及如何造成内存碎片，多核、多线程场景下，性能如何低的讨论，甚至分析了另外两种内存分配器jemalloc（Facebook家的）、tcmalloc（Google家的）的性能如何如何厉害。
最后，实在是走投无路了，干脆直接把ptmalloc换了，正好buildroot支持jemalloc编译，顺其自然的，我就把jemalloc换上了。不换不知道，一换吓一跳，应用虚拟内存使用直接从500M降到了60M，当时直接给jemalloc跪了。
后来，才知道虚拟内存大小降了那么多，不是jemalloc的功能，而是由于使用了Asan虚拟内存使用量才上来的，也正是由于Asan需要实时监测内存使用情况，才最终导致了内存的不断增长。
哈哈，彻底理解了程序猿经常为了体验新的技术，自己挖坑，自己跳，自己埋的故事了。
总结几点经验:
- 项目开发过程中，新技术、新工具要慎用，用之前，要充分了解，过程中要做好使用记录，待问题出现时，可以反过来找问题的可能原因。
- 对于新技术、新工具要有一点免疫力，不要头脑发热，看到它鼓吹的功能、性能，就恨不得马上应用到项目里，这样其实往往是在给自己挖坑，最后自己怎么死的都不知道。
- 最后，新技术、新工具不是不学，不用了，反而要时刻保持一颗积极探索的心态，碰到好的东西，要积极学习，等待想法成熟之后，再应用到实际工作中去。
当然，从这次事件中也学到了很多，比如大概了解了常用的几款内存分配器的原理和使用方式，了解了Asan和valgrind的基本原理和使用方式，这些对以后的工作都是大有用处的，算是因祸得福
吧，哈哈。