-
asan（addresssanitizer的缩写）是一款面向c/c 语言的内存错误问题检查工具，可以检测如下内存问题：
- 使用已释放内存（野指针）
- 堆内存越界（读写）
- 栈内存越界（读写）
- 全局变量越界（读写）
- 函数返回局部变量
- 内存泄漏
asan工具主要由两部分组成：
- 编译器插桩模块
- 运行时库
运行时库：（libasan.so.x）会接管
malloc和``free函数。malloc执行完后，已分配内存的前后（称为“红区”）会被标记为“中毒”状态，而释放的内存则会被隔离起来（暂时不会分配出去）且也会被标记为“中毒”状态。编译器插桩模块：加了asan相关的编译选项后，代码中的每一次内存访问操作都会被编译器修改为如下方式：
编译前:
*address = ...; // or: ... = *address;编译后：
if (ispoisoned(address)) { reporterror(address, kaccesssize, kiswrite); } *address = ...; // or: ... = *address;该方式的关键点就在于读写内存前会判断地址是否处于“中毒”状态，还有如何把
ispoisoned实现的非常快，把``reporterror实现的非常紧凑，从而避免插入的代码过多。asan对缓冲区溢出防护的的基本步骤如下：
\1. 通过在被保护的栈、全局变量、堆周围建立标记为中毒状态(poisnoned)的red-zones；
以栈缓冲区溢出检测为例，如下代码展示了red-zone的建立。
将缓冲区和red-zone通过每8字节对应1字节的映射的方式建立影子内存区，影子内存区的获取函数为memtoshadow。
\3. 如果出现对red-zone的读、写或执行的访问，则asan可以shadowispoisoned检测出来并报错。
报错信息给出出错的源文件名、行号、函数调用关系、影子内存状态。其中影子内存状态信息中出错的部分用中括号标识出来。如下所示：
二. 内存映射与插桩
进程的虚拟内存空间被asan划分为2个独立的部分：
- 主应用内存区 (
mem): 普通app代码内存使用区。 - 影子内存区 (
shadow): 该内存区仅asan感知，影子顾名思义是指该内存区与主应用内存区存在一种类似“影子”的对应关系。asan在将主内存区的一个字节标记为“中毒”状态时，也会在对应的影子内存区写一个特殊值，该值称为“影子值”。
这两个内存区需要精心划分，确保可以快速从主应用内存区映射到影子内存区(
memtoshadow)。主应用内存与影子内存shadow bytes映射
asan将8字节的主应用区内存映射为1字节的影子区内存。
针对任何8字节对齐的主应用区内存，总共有9种不同的影子内存值：
-
4字中的全部8字节都未“中毒”(可访问的)，影子值是0。
-
4字中的全部8字节都“中毒”(不可访问的)，影子值是负数。
-
前
k个字节未“中毒”，后8-k字节“中毒”，影子值是``k。这一功能的达成是由malloc函数总是返回8字节对齐的内存块来保证的，唯一能出现该情况的场景就在申请内存区域的尾部。例如，我们申请13个字节，即malloc(13)，这样我们会得到一个完整的未“中毒”的4字和前5个字节未“中毒”、后3个字节“中毒”的4字。
asan日志格式
每条错误记录都是以一串"="号开始的，具体内容包含(重点关注标红的字段)：
错误进程号：内存问题发生的linux进程号
错误类型：global-buffer-overflow/(全局变量越界), heap-buffer-overflow 堆内存越界, stack-buffer-overflow栈内存越界, double-free（重复释放内存） 内存越界调用栈：重复内存错误的调用栈信息，如果要显示文件名行号，需要加-g选项 上次内存释放调用栈：上一次释放内存的调用栈信息 内存申请调用栈：内存申请的调用栈信息
越界地址说明：对出错时访问的内存地址做进一步说明，以便更直观的判断问题所在影子内存状态、影子内存魔术字、asan内部信息，分析问题是可不关注
分析asan报错日志
==7829==error: leaksanitizer: detected memory leaks direct leak of 7 byte(s) in 1 object(s) allocated from: #0 0x42c0c5 in __interceptor_malloc /usr/home/lib/asan/asan_malloc_linux.cc:74 -- 泄漏内存的申请调用栈 #1 0x43ef81 in main /usr/home/memory-leak.c:5 #2 0x7fef044b876c in __libc_start_main /build//glibc-2.15/csu/libc-start.c:226 summary: addresssanitizer: 7 byte(s) leaked in 1 allocation(s).上面的代码内存泄漏很明显，第6行代码将保存申请内存的p指针置空，导致内存泄漏了；而生成的日志内容也挺简单：
"7829"表示程序的进程号，后面的"error:"表明asan发现了内存泄漏，如果没有发现内存泄漏，这些信息都不会打，也不会生成相关日志；
换一行的"leak of 7 byte(s)"表明内存泄漏了7个字节，"1 object(s)“表明泄漏了1次，而泄漏内存的申请调用栈就在后面打印了，其中”/usr/home/memory-leak.c:5"表明内存申请的文件名、行号。
函数插桩
可以自定制新开发功能，基于asan（addresssanitizer的缩写）的文件句柄问题检查功能， 采用ld_preload机制和dlsym接口，接管libc库的open/close等接口，并进行判断与调用栈记录。就像asan使用自定义的运行时库函数接管malloc/free，new/delete，mem*等函数。
asan内存泄漏检测原理如下：
1、asan会接管内存申请接口，即用户的内存全都由asan来管理；
2、当进程退出时触发asan内存泄漏检测，开发可以使用复位单板、重启设备等一切可以让进程正常退出的方法来触发asan进行内存泄漏检测；
3、开始内存泄漏检查后，asan会遍历当前所有已经分配给用户但没有释放的堆内存，扫描这些内存是否被某个指针引用着，这些指针可能是全局变量、局部变量或者是堆内存里面的指针，如果没有则认为是泄漏了；如果内存被引用着，比如内存申请完后放在v8的local数据区、插树、插链表等，是不会报泄漏的；
4、将所有泄漏的内存信息打出来，包含内存大小和内存申请的调用栈信息；
因此，如果日志中报内存泄漏了，开发同学需要分析该内存申请的指针是存放到哪儿的，在流程中这个指针是在哪儿被改了，但是没有释放内存。
讲一个会导致内存泄漏的场景，某基础模块发现4个内存泄漏问题，都是内存申请后存放到全局变量中，开发说该内存会一直使用不释放，不算泄漏，但实际上该全局变量会被初始化两次，第二次没有判断全局变量是否已经初始化，而直接赋成新的内存指针值，导致泄漏。
已知asan内存泄漏误报场景：
1、结构体非4字节对齐：例如报结构体a内存泄漏，且a内存的指针存放在结构体b中，由于asan扫描内存时是按4字节偏移进行的，所以如果a指针在结构体b中的偏移非4的整数倍，asan就扫不到，出现误报（主干要求：非4字节对齐的结构体需要整改）；
2、信号栈内存：该内存是在信号处理函数执行时做栈内存用的，其指针会保存到内核中，所以asan扫描不到，产生误报；
3、内存指针偏移后保存：有子系统代码实现比较特殊，将申请的内存指针做一个很大的偏移（超过该内存的合法范围）操作后保存起来，通过偏移后的值asan根本找不到对应的内存，所以误报泄漏；
4、存在asan未监控的内存接口
asan使用要添加的编译选项
-fsanitize=address -fsanitize=undefined -fsanitize=leak -fsanitize-recover=all -fno-omit-frame-pointer -fno-stack-protector -fsanitize=leak
set(cmake_c_flags " -m64 -wno-write-strings -fgnu89-inline -fexceptions -fno-inline -rdynamic -fsanitize=address -fsanitize-recover=all -fsanitize=leak")
set(cmake_cxx_flags " -std=c 11 -m64 -wno-write-strings -fexceptions -fno-inline -rdynamic -fsanitize=address -fsanitize-recover=all -fsanitize=leak")
-fsanitize=address -fsanitize=undefined -fsanitize=leak -fsanitize-recover=all -fno-omit-frame-pointer -fno-stack-protector -fsanitize=leak