QuickJS项目中ASAN故障调试的优化实践

在QuickJS项目的持续集成测试过程中，开发团队遇到了一个调试难题：当AddressSanitizer（ASAN）检测到内存错误时，测试日志中无法直观看出具体是哪个测试用例导致了失败。这个问题在PR #844的CI运行结果中表现得尤为明显。

问题背景

AddressSanitizer是Google开发的内存错误检测工具，能够帮助开发者发现诸如缓冲区溢出、使用释放后内存等常见内存问题。在QuickJS这样涉及复杂内存管理的JavaScript引擎项目中，ASAN是保证代码质量的重要工具。

然而，当测试套件（特别是像test262这样的大型测试集）运行时，如果某个测试用例触发了ASAN错误，默认的输出往往只显示内存错误本身，而不包含足够的上文信息来定位是哪个具体测试文件导致了问题。

解决方案探索

开发团队考虑了两种可能的解决方案：

1. 修改测试运行参数：通过给run-test262添加-vv -t 1参数，启用详细输出模式和单线程运行方式。这样做可以：

   • -vv参数提供更详细的日志输出
   • -t 1强制单线程执行，避免多线程环境下日志交错的问题

2. 直接代码修改：在测试框架中添加显式的文件名输出，如在执行每个测试文件前打印printf("filename %s\n", filename);。这种方法虽然简单直接，但需要考虑：

   • 输出格式是否会影响后续的日志解析
   • 是否需要额外的日志级别控制
   • 在多线程环境下的输出同步问题

技术决策

最终，开发者选择了第二种方案，通过在代码中添加显式的文件名打印来解决调试难题。这种方案的优势在于：

• 实现简单，无需修改构建或测试流程
• 输出直观，直接显示当前执行的测试文件
• 对现有测试框架的侵入性小

对开发实践的启示

这个案例给我们的启示是：

1. 调试信息要充分：在自动化测试中，确保失败时能提供足够的上下文信息至关重要
2. 平衡简洁与详细：测试输出需要在简洁性和详细性之间找到平衡点
3. 考虑多线程影响：现代测试框架往往并行执行测试，需要确保调试输出在多线程环境下仍然可读

对于类似项目的开发者，当遇到ASAN或其他工具报告的错误难以定位时，可以考虑：

• 增强测试框架的上下文输出
• 控制测试的并行度以简化调试
• 在关键执行点添加标记性输出

通过这样的实践，可以显著提高内存错误调试的效率，加快问题定位和修复的速度。