遵循Sanitizer Github建议后，AddressSanitizer仍破坏GDB状态
2026-8-4
解决AddressSanitizer在GDB中终止会话且无法获取栈信息的问题
我碰到了double-free漏洞，用开启AddressSanitizer（AS）的Debug构建能复现这个问题，但在GDB里运行时，AS会直接终止GDB会话。我查了AS的官方调试指南，按建议在会话开始时执行了(gdb) break __asan::ReportGenericError这个命令，可漏洞被检测到后GDB还是丢了状态，执行(gdb) bt显示No stack.
调整AS的错误处理行为
默认情况下，AS检测到内存错误后会直接终止进程，导致GDB丢失上下文。你可以通过环境变量让AS在报错后暂停而非退出：
- 启动GDB前设置：
export ASAN_OPTIONS=abort_on_error=0:halt_on_error=1 - 或者在GDB内部设置：
(gdb) set environment ASAN_OPTIONS=abort_on_error=0:halt_on_error=1
优化断点设置
__asan::ReportGenericError可能不是最精准的断点，针对double-free场景，试试这些更直接的断点：
- 断在double-free的专属报告函数：
(gdb) break __asan::ReportDoubleFree - 或者断在AS的通用错误报告入口：
(gdb) break __asan_report_error
确保工具链版本兼容
老版本GDB可能和新版AS存在兼容性问题，导致断点失效或栈信息丢失。建议升级GDB到最新稳定版，或者使用和编译程序时相同的工具链自带的GDB（比如clang或gcc配套的GDB）。
完整调试流程示例
- 启动GDB前配置环境变量：
export ASAN_OPTIONS=abort_on_error=0:halt_on_error=1 gdb ./your_debug_binary - 在GDB中设置断点并运行：
break __asan::ReportDoubleFree run - 断点命中后，执行
bt就能看到完整的调用栈，定位double-free的触发位置了。
内容的提问来源于stack exchange，提问作者intrigued_66
相关产品推荐
相关产品推荐
