为何AddressSanitizer在Nginx中未检测出heap-use-after-free错误

• 内存分配器未被ASan hook
  Nginx默认实现了自有内存池机制，内部大量使用ngx_palloc/ngx_pfree等自定义分配接口，而非直接调用glibc的malloc/free。如果你的测试代码用了Nginx封装的内存分配接口，或是Nginx编译时链接了jemalloc、tcmalloc等第三方内存分配器，ASan默认的malloc/free hook无法捕获内存的分配释放行为，自然无法检测UAF问题。
• 编译链接参数未全量生效
  ASan要求编译、链接两个阶段都添加对应参数，部分用户编译Nginx时仅修改了CFLAGS，遗漏了LDFLAGS的asan配置，会导致ASan未实际注入检测逻辑。同时要确认自定义http模块的编译参数也携带了asan相关配置，避免模块代码未被插桩。
• ASan日志输出被重定向/屏蔽
  Nginx采用master-worker多进程模型，运行时worker进程的标准错误输出默认会被重定向到Nginx的错误日志文件（路径由配置文件error_log指令指定），而非直接输出到终端。你可以检查对应错误日志文件，确认是否有ASan的报错信息被写入到日志中而非终端。
  此外如果以root身份运行带setuid属性的Nginx二进制，ASan为了安全会默认关闭检测功能，需要配置环境变量ASAN_OPTIONS=allow_suid_exec=1才会正常执行检测。
• fsanitize-recover=address参数的影响
  你添加的fsanitize-recover=address参数允许ASan在检测到错误后不中止进程、继续运行，如果进程此前已经触发过其他ASan错误且未中止，后续的错误日志可能会被丢弃。你可以调整编译参数移除fsanitize-recover=address，同时添加环境变量ASAN_OPTIONS=abort_on_error=1，触发错误时直接中止进程方便排查。
• 内存访问操作被优化/对齐特殊处理
  确认你的测试代码中对已释放内存的访问操作没有被编译器优化消除，即使你用printf输出了对应值，也可以尝试添加-O0编译参数关闭优化复现测试，排除优化导致的插桩遗漏。

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