启用AddressSanitizer的C程序无堆栈跟踪触发DEADLYSIGNAL崩溃，求助排查方案
我完全理解你现在的头疼——ASAN本来是排查内存问题的利器，结果它自己先无征兆崩溃，连堆栈都不给，换Valgrind和GDB又复现不了，这种情况确实让人摸不着头脑。结合你给出的代码、Makefile和运行日志，我给你整理了几个针对性的排查方向：
先解决ASAN函数拦截失败的核心问题
你的ASAN日志里反复出现failed to intercept '__isoc99_printf'这类错误，这是关键线索！ASAN依赖拦截标准库函数来监控内存操作，如果拦截失败，它不仅无法正常检测内存问题，连崩溃时的堆栈跟踪都生成不了。试试这些操作：
检查GCC与系统libc的版本兼容性
先运行gcc -v和ldd --version确认版本：旧版GCC（比如8.x及以下）的ASAN模块和较新的libc（或反之）可能存在函数签名不兼容的问题，直接导致拦截失败。如果你的GCC版本低于9，建议升级到最新稳定版试试。临时切换编译优化等级到-O0
你的Makefile里用了-O1，虽然ASAN官方推荐O1，但某些场景下O1的优化会干扰ASAN的函数钩子逻辑。把CFLAGS里的-O1改成-O0，重新编译后再运行，看看崩溃时能不能生成有用的堆栈。清理LD_PRELOAD环境变量
有时候系统中预加载的其他调试库（比如Valgrind残留的库、第三方监控库）会和ASAN的拦截逻辑冲突。运行unset LD_PRELOAD后再启动程序，排除这种干扰。
排查环境与文件系统的边缘影响
你是在挂载的SSD（/media/yegane/my-ssd）上运行程序，非本地根文件系统可能触发ASAN的一些罕见问题：
把项目移到本地目录编译运行
复制整个项目到~/tmp这类本地目录，重新编译启动。某些挂载的文件系统（比如NTFS、exFAT）的权限、缓存机制或特性会影响ASAN的内存映射、日志写入等核心操作，导致异常崩溃。手动配置ASAN日志的写入权限
你设置了log_path=asan.log但日志没生成有用内容，试试手动创建日志文件并赋予全写入权限：touch asan.log && chmod 666 asan.log再用
ASAN_OPTIONS=verbosity=2:log_path=asan.log ./build/my_program启动，看是否能生成完整的初始化和崩溃日志。
用GDB强制捕捉原始崩溃点
你说GDB无法复现崩溃，但试试用GDB直接运行ASAN编译的程序，强制捕捉信号：
- 启动GDB：
gdb ./build/my_program - 在GDB里设置信号捕捉规则：
handle SIGSEGV stop print - 运行程序：
run - 如果程序崩溃，立即执行
bt full查看完整堆栈跟踪——哪怕ASAN没生成日志，GDB本身也能捕捉到原始的崩溃位置。
针对你的最小测试程序的额外检查
你的最小getline程序语法和逻辑都没问题，但你说它会崩溃，可能是测试场景的问题？试试用空输入重定向测试：
./fixed < /dev/null
如果这时候触发崩溃，那可能是ASAN在处理getline的EOF场景时的特定bug，升级GCC版本通常能解决这类问题。
内容来源于stack exchange
