QuickJS 内存泄漏问题分析与修复

在 QuickJS 轻量级 JavaScript 引擎中，开发者发现了一个值得关注的内存泄漏问题。这个问题出现在字符串处理函数 padEnd() 的实现中，当处理异常大的字符串长度参数时会触发内存泄漏。

问题现象

当使用 padEnd() 函数并传入接近 JavaScript 引擎限制的极大长度参数（如 2147483620）时，虽然引擎正确地抛出了"invalid string length"的 RangeError 异常，但在错误处理过程中却未能正确释放之前分配的内存。通过 AddressSanitizer 工具可以检测到 18 字节的内存泄漏。

技术分析

这个内存泄漏问题出现在两种不同的使用场景中：

1. 使用数字 0 作为填充内容时：

v1 = '';
v2 = v1.padEnd(2147483620, 0);

2. 使用字符串 '0' 作为填充内容时：

v1 = '';
v2 = v1.padEnd(2147483620, '0');

在两种情况下，引擎都会在执行 padEnd 操作前尝试将填充参数转换为字符串。这个转换过程会分配内存来创建新的字符串对象。当后续检查发现请求的字符串长度超出限制时，虽然抛出了异常，但之前分配的字符串内存却没有被正确释放。

底层机制

QuickJS 的内存管理采用引用计数机制。正常情况下，当对象不再被引用时应该自动释放。在这个案例中，异常路径上的错误处理逻辑存在缺陷，导致某些临时创建的字符串对象没有被正确释放。

从调用栈可以看出，内存分配发生在 JS_ToStringInternal 函数中，这是将填充参数转换为字符串的关键步骤。当转换完成后，引擎检查字符串长度时发现异常，直接抛出错误，但忘记释放之前创建的字符串对象。

修复方案

QuickJS 开发者已经修复了这个问题。修复的关键在于确保在错误处理路径上正确释放所有已分配的资源。具体措施可能包括：

1. 在抛出异常前，显式释放临时创建的字符串对象
2. 优化错误处理流程，确保资源释放逻辑覆盖所有异常路径
3. 加强测试用例，覆盖各种边界条件下的内存管理情况

开发者启示

这个案例给 JavaScript 引擎开发者提供了重要启示：

1. 异常处理路径上的资源管理同样重要，不能只关注正常执行路径
2. 边界条件测试（如极大值参数）对于发现内存问题至关重要
3. 使用内存检测工具（如 AddressSanitizer）可以帮助发现潜在的内存管理问题
4. 引用计数机制虽然简单高效，但在复杂控制流中需要格外小心

对于 QuickJS 这样的嵌入式 JavaScript 引擎来说，稳健的内存管理尤为重要，因为这类引擎通常运行在资源受限的环境中，任何内存泄漏都可能对长期运行的应用程序造成严重影响。