SQLC WASM插件加载错误导致SIGSEGV问题分析

在SQLC 1.27.0版本中，当WASM插件加载失败时，程序会抛出SIGSEGV(段错误)异常。这个问题源于SQLC与Wazero运行时之间的交互不当，特别是在错误处理流程中对WASM模块的关闭操作上。

问题背景

SQLC是一个流行的SQL转Go代码生成工具，它支持通过WASM插件扩展功能。Wazero是一个零依赖的WebAssembly运行时，SQLC使用它来执行这些插件。当插件加载或执行失败时，SQLC会尝试清理资源，包括关闭WASM模块。

根本原因

问题的核心在于错误处理流程中的双重关闭尝试。具体来说：

1. Wazero运行时在检测到错误时已经自动关闭了WASM模块
2. SQLC的错误处理代码中又显式调用了模块的Close方法
3. 这导致对已关闭模块的非法内存访问，触发段错误

在SQLC的wasm.go文件中，Invoke方法在错误处理路径中无条件地调用了result.Close()，而没有考虑Wazero可能已经关闭了模块的情况。

技术细节

当WASM插件执行失败时，Wazero内部会：

1. 设置模块的退出码
2. 释放模块占用的资源
3. 将模块标记为已关闭

此时模块实例的内部状态已经无效。SQLC随后尝试再次关闭这个模块，访问了已经释放的内存，导致段错误。从调用栈可以看到，崩溃发生在wazero内部尝试设置退出码的位置，这正是因为模块实例指针已经无效。

解决方案

正确的处理方式应该是：

1. 检查模块是否已经处于错误状态
2. 仅在模块仍活跃时执行关闭操作
3. 或者完全依赖Wazero的自动清理机制

SQLC团队在后续提交中修复了这个问题，移除了冗余的关闭调用，避免了双重释放的情况。

经验教训

这个案例展示了与外部运行时交互时需要特别注意的几个方面：

1. 必须清楚了解运行时对资源生命周期的管理策略
2. 错误处理路径中的资源清理需要格外谨慎
3. 双重释放是C/C++/Go等语言中常见的安全隐患
4. 与WASM等沙箱环境交互时，需要遵循其特定的资源管理约定

对于开发者来说，当集成类似Wazero这样的复杂运行时系统时，仔细阅读其文档中关于资源管理的部分至关重要，特别是错误情况下各方的责任划分。