升级Debian后segfault无法被gdb/valgrind捕获的问题咨询

这类故障属于典型的内存布局敏感型海森堡bug，调试器、valgrind启动时会修改堆分配策略、环境变量、内存映射起始地址，导致非法内存写入碰不到会触发崩溃的敏感位置，按以下优先级排查即可，不需要逐行读代码：

1. 优先用glibc原生堆检测触发故障（零代码修改成本） #

bullseye 自带的 glibc 2.31 内置堆完整性校验，不需要重编译程序，直接设置环境变量后启动裸程序即可，不要通过gdb/valgrind启动（调试器会默认重置这类malloc相关环境变量）：

# 开启最高等级堆校验，遇到堆元数据篡改直接终止，不做容错
export MALLOC_CHECK_=3
# 所有分配/释放的内存填充随机非零值，提前触发悬垂指针、未初始化内存问题
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
# 直接启动程序复现操作
./your_program

如果是堆元数据被篡改，程序会在非法操作发生时直接崩溃，生成的core可以拿到比realloc崩溃点更靠前的调用栈。

2. 用AddressSanitizer定位非法写入位置 #

如果原生堆检测没抓到具体篡改位置，用AddressSanitizer（ASAN）插桩编译，检测精度远高于valgrind，运行速度仅比原生程序慢2倍左右，不会像valgrind那样慢10-20倍导致内存布局大幅偏移：

• 编译和链接阶段统一加参数：-fsanitize=address -fno-omit-frame-pointer -g，确保所有参与编译的源码文件都加了该参数，不要混用开了ASAN和没开ASAN的静态库
• 启动程序前设置ASAN运行参数，尽量贴近原生内存布局，避免问题消失：

export ASAN_OPTIONS=abort_on_error=1:disable_coredump=0:malloc_context_size=30:detect_leaks=0
./your_compiled_program

ASAN会在每块堆、栈、全局内存的前后加只读保护区，只要出现越界写、use-after-free、double free、篡改堆元数据的操作，会直接在非法写入发生的瞬间抛出错误，打印完整调用栈，不需要等到调用realloc访问坏指针才崩溃。

把realloc替换为malloc+memcpy且不释放旧指针后程序正常运行，本质是绕过了对被篡改堆元数据的校验，并没有修复根因，ASAN可以直接抓到这类问题。

3. 硬件断点精准抓指针篡改现场 #

如果前两种方法都因为内存布局变化导致问题无法复现，就用硬件断点抓，完全不改动程序内存布局：

1. 先直接运行裸程序复现崩溃，保留core dump文件
2. 从core里找到传给realloc的坏指针实际存储的内存地址——注意不是指针本身的值，是存这个指针的变量所在的地址（可能是栈上局部变量、全局变量、堆块里的成员变量）
3. 重新启动程序，不要从gdb内部启动，等程序运行完成初始化、内存布局稳定后，用gdb附加到运行中的进程：gdb -p $(pidof your_program)
4. 在gdb里对刚才找到的指针存储地址下硬件写断点：watch *0x<你找到的存储地址>，硬件断点由CPU支持，不会修改程序代码或内存布局
5. 继续运行程序，执行触发故障的操作，只要有代码往这个指针存储的位置写入值，程序就会断下，此时的调用栈就是篡改指针的代码位置。

4. 针对性排查bullseye版本兼容问题 #

如果以上方法还没定位到，可以先排查新旧系统差异导致的老代码兼容问题：

• 临时关闭ASLR测试：执行echo 0 > /proc/sys/kernel/randomize_va_space（需要root权限），如果关闭后故障消失，说明代码存在指针计算依赖固定内存地址、整数溢出导致指针偏移错误的问题
• 预加载其他malloc实现测试：比如预加载tcmalloc/jemalloc运行程序，如果故障现象变化，基本可以确定是堆上的小范围越界写入——旧版Debian的ptmalloc分配器中，越界位置刚好是未使用的填充字节，新版ptmalloc调整了堆块布局，越界刚好写到堆元数据或相邻堆块的指针成员触发崩溃。

内容的提问来源于stack exchange，提问作者Tiamat