4、AddressSanitizer (ASan) 集成：在GCC/Clang中开启ASan，快速发现缓冲区溢出

内存问题里，缓冲区溢出是最让人头疼的。你想想看，一个数组越界写，可能当时不崩，过几个小时才在另一个函数里莫名其妙挂掉。这种 bug 最难复现，也最难定位。

AddressSanitizer（简称 ASan）就是专门干这个的。它能在编译阶段插入检测代码，运行时一旦发生越界访问、释放后使用、栈溢出等问题，立刻报错并打印调用栈。我个人的习惯是：开发阶段一律开 ASan，跑通所有用例后再关掉做性能测试。

4.1 ASan 的工作原理

ASan 的核心思路很简单——在内存周围布置「毒药」。它把堆、栈、全局变量的周围都映射上不可访问的 shadow memory，任何越界读写都会触发 SIGSEGV，然后 ASan 捕获信号并输出诊断信息。

具体来说，ASan 做了三件事：

• 影子内存（Shadow Memory）：每 8 字节用户内存对应 1 字节影子内存，记录这 8 字节是否可访问。
• 红区（Redzone）：在每次分配的堆内存前后各加一段不可访问的区域，越界读写会立刻触发异常。
• 栈和全局变量保护：对栈上的局部变量和全局变量也插入红区检测。

我在项目中遇到过这样一个案例：一个固件在运行 72 小时后随机死机，开 ASan 后第一次跑就抓到了——一个全局数组在中断服务函数里被写越界了 4 个字节。没有 ASan，这种问题可能要排查两周。

4.2 在 GCC/Clang 中开启 ASan

开启方式极其简单，编译和链接时加上 -fsanitize=address 就行。我建议再加几个辅助选项：

# 最基本的开启方式
gcc -fsanitize=address -g -O1 -o test test.c

# 我常用的完整选项
gcc -fsanitize=address \
    -fsanitize-recover=address \
    -fno-omit-frame-pointer \
    -g -O1 \
    -o test test.c

选项	作用	我为什么加它
-fsanitize=address	开启 ASan	核心选项，必须加
-g	生成调试信息	没有它，报错时看不到行号
-O1	轻度优化	O0 太慢，O2 可能干扰检测，O1 最平衡
-fno-omit-frame-pointer	保留帧指针	让调用栈更完整，定位更准
-fsanitize-recover=address	出错后继续运行	一次跑出所有错误，不用修一个跑一次

4.3 实战：抓一个缓冲区溢出

来看一个典型的堆缓冲区溢出例子：

#include <stdlib.h>
#include <string.h>

int main() {
    char *buf = (char*)malloc(16);
    // 越界写！buf 只有 16 字节，却写了 24 字节
    memset(buf, 0xAA, 24);
    free(buf);
    return 0;
}

编译运行：

$ gcc -fsanitize=address -g -O1 -o overflow overflow.c
$ ./overflow

ASan 会输出类似这样的信息：

=================================================================
==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000014
WRITE of size 24 at 0x602000000014 thread T0
    #0 0x4006c4 in main overflow.c:7
    #1 0x7f1234567890 in __libc_start_main
    #2 0x4005a9 in _start

0x602000000014 is located 0 bytes to the right of 16-byte region
allocated by thread T0 here:
    #0 0x4005e8 in malloc
    #1 0x4006a8 in main overflow.c:5

看到没？它直接告诉你：

• 错误类型：heap-buffer-overflow（堆缓冲区溢出）
• 操作：WRITE of size 24（写了 24 字节）
• 位置：overflow.c:7（第 7 行）
• 分配位置：overflow.c:5（第 5 行分配的）

这就是 ASan 的价值——把几天的排查工作缩短到几分钟。

4.4 ASan 能检测的常见问题

问题类型	ASan 报错信息	典型场景
堆缓冲区溢出	heap-buffer-overflow	malloc 后写越界
栈缓冲区溢出	stack-buffer-overflow	局部数组越界
全局缓冲区溢出	global-buffer-overflow	全局数组越界
释放后使用	heap-use-after-free	free 后继续读写
双重释放	double-free	同一块内存 free 两次
内存泄漏	leak-sanitizer	未释放的堆内存

4.5 嵌入式环境下的特殊考虑

嵌入式开发用 ASan 会遇到一些实际问题。我踩过不少坑，分享几个关键点：

• 内存不够？ ASan 需要额外 2-3 倍内存。在只有 64KB RAM 的 MCU 上基本跑不了。建议在 Linux 开发板或模拟器上跑。
• 交叉编译：需要目标平台的 ASan 运行时库。用 --sysroot 指定工具链路径，确保 libasan.so 能链接进去。
• RTOS 环境：FreeRTOS 等系统需要特殊配置。我记得有个项目在 FreeRTOS 上开 ASan，结果任务栈检测不准——因为 ASan 默认用 pthread 的 TLS，RTOS 里没有。后来手动映射了影子内存才搞定。
• 性能影响：代码变慢 2-3 倍，实时任务可能受影响。我一般只在单元测试和集成测试时开，正式跑负载时关掉。

4.6 ASan 与其他工具的对比

工具	检测方式	速度	内存开销	适用场景
ASan	编译插桩	慢 2-3x	+2-3x	开发阶段快速定位
Valgrind	动态二进制插桩	慢 10-20x	+10-20x	无法重新编译的场景
UBSan	编译插桩	慢 1.5x	+0.5x	未定义行为检测
静态分析	源码分析	快	无	代码审查阶段

我个人习惯的组合是：开发时开 ASan + UBSan，提交前跑一遍 Valgrind 做补充，静态分析集成到 CI 里每天跑。这样基本能覆盖 90% 以上的内存问题。

4.7 ASan 检测流程总览

下面这张图展示了 ASan 从编译到报错的完整流程：

流程其实不复杂：源码经过编译插桩后，每个内存操作都被包裹了检测代码。运行时一旦踩到红区，ASan 立即捕获并输出报告。正常路径（绿色）和异常路径（红色）在运行时动态切换。

4.8 避坑指南

最后分享几个我踩过的坑：

• 链接顺序问题：ASan 库必须放在链接命令的最后。我曾经把 -lasan 放在前面，结果链接器用了标准库的 malloc，ASan 完全没生效。
• 动态库也要开 ASan：如果主程序开了 ASan 但动态库没开，动态库里的内存错误检测不到。所有模块都要统一加 -fsanitize=address。
• fork 后的子进程：ASan 默认不跟踪子进程。需要设置环境变量 ASAN_OPTIONS=detect_leaks=1:detect_odr_violation=0 来开启。
• 不要在生产环境开：这个不用多说，性能开销太大。但可以在生产环境的 debug 版本里开，用于现场复现问题。