消毒器手册：内存、初始化与竞态
内容提要
该文介绍AddressSanitizer、LeakSanitizer、MemorySanitizer和ThreadSanitizer四种工具，它们通过运行时检查内存地址性、泄漏、初始化状态和线程同步，揭示正确结果下的隐藏缺陷。文章强调工作负载设计、工具链支持及CI策略的重要性，并以webcrypto.dart案例说明FFI所有权管理，最终指出清洁运行仅证明特定执行未违反可观察契约。
延伸解读
正确结果不等于有效执行
文章强调，功能正确性与执行有效性是两回事。一个函数可能返回正确结果，但底层存在未初始化读取、所有权转移错误或数据竞争。这些缺陷在常规测试中可能被掩盖，直到特定时机才暴露。理解这一区别是使用消毒器的前提，也是设计测试和工作负载的关键。
消毒器各有侧重，需组合使用
ASan、LSan、MSan和TSan分别关注地址性、泄漏、初始化状态和线程同步。它们不是同一调试模式的不同变体，而是观察执行的不同属性。实际应用中，需要根据代码特点选择合适的工具，并理解其局限性，例如未插桩代码或自定义分配器可能影响检测效果。
FFI边界是所有权问题的重灾区
在Dart、Java、Python等语言与原生代码交互时，所有权和生命周期规则跨越两个运行时，容易出错。文章以webcrypto.dart为例，展示了FFI中句柄转移、finalizer和清理作用域的管理复杂性。消毒器能帮助发现这些边界上的隐藏缺陷，但需要精心设计工作负载以覆盖相关路径。
清洁运行并非安全证明
消毒器通过一次运行只能证明该次执行中未违反其可观察的契约，不能保证代码绝对安全。未插桩的模块、未覆盖的路径、隐藏的同步机制等都可能使缺陷逃过检测。因此，清洁运行后应思考：这次运行实际观察到了什么？哪些部分仍在视野之外？
Q&A
AddressSanitizer、LeakSanitizer、MemorySanitizer和ThreadSanitizer分别检测什么？
AddressSanitizer（ASan）检测内存地址性和生命周期问题，如越界访问、释放后使用等；LeakSanitizer（LSan）检测内存泄漏，即进程结束时仍未被释放且不可达的分配；MemorySanitizer（MSan）检测未初始化内存的使用；ThreadSanitizer（TSan）检测数据竞争，即并发访问未同步的问题。
为什么程序输出正确但仍然可能存在内存错误？
因为功能正确性和执行有效性是两个不同概念。程序可能返回正确结果，但底层存在未初始化的变量、所有权转移错误、内存泄漏或数据竞争等问题。这些错误不会立即影响输出，但可能在特定条件下导致崩溃或安全漏洞。消毒器通过运行时检查来揭示这些隐藏的缺陷。
如何理解消毒器报告中的调用栈？
消毒器报告中的调用栈通常不是错误的根源，而是错误暴露的位置。例如，ASan的use-after-free报告会包含分配、释放和当前访问三个栈，分别显示对象生命周期开始、结束和错误访问的位置。修复应关注所有权转移或生命周期管理的错误，而不是仅仅在崩溃点添加检查。
在FFI边界上，所有权管理常见哪些问题？
在FFI边界上，常见问题包括：包装器错误地释放了借用的句柄；所有权转移后仍保留finalizer导致双重释放；引用计数未正确管理导致泄漏；以及初始化状态未正确传递。例如，BoringSSL的get0/get1/set0/set1约定区分了借用和拥有引用，如果包装器忽略这些约定，就会导致错误。
为什么消毒器需要配合适当的工作负载设计？
消毒器只能检测到执行过程中发生的违规。如果工作负载没有覆盖到错误路径，消毒器就无法发现缺陷。因此，需要设计能触发所有权转移、失败路径、并发交错等场景的工作负载，例如生命周期压力测试、模糊测试、故障注入和并发探测，以增加发现问题的机会。
如何设置ASan的编译和运行选项以获取有用的报告？
编译时建议使用`-O1 -g -fno-omit-frame-pointer -fno-optimize-sibling-calls -fsanitize=address`，以保留调试信息和帧指针，避免优化导致栈信息丢失。运行时设置`ASAN_SYMBOLIZER_PATH`指向llvm-symbolizer，并启用`detect_leaks=1`和`check_initialization_order=1`。这样能生成可解释的崩溃报告。
LeakSanitizer的局限性是什么？
LeakSanitizer的局限性在于它基于可达性判断泄漏，而不是基于程序意图。如果内存仍然可达（例如被全局变量引用），即使程序本应释放它，LSan也不会报告。此外，LSan在进程退出时检查，可能遗漏异步清理或依赖finalizer的释放。因此，需要设计合适的测试生命周期来准确测量所有权。
为什么抑制（suppression）不能作为修复策略？
抑制会隐藏问题，改变消毒器运行的意义。如果抑制范围过宽，可能会掩盖新的回归。抑制应仅用于临时处理第三方库或平台问题，并需记录原因和复审时间。对于自己拥有的代码，应修复问题而不是抑制。
