LLRT项目中ReadableStream内存泄漏问题的分析与解决

问题背景

在LLRT（Lightweight JavaScript Runtime）项目使用过程中，开发者发现当引入axios库时会触发运行时崩溃。经过深入排查，发现问题根源在于ReadableStream对象的创建过程中存在内存管理缺陷，导致JavaScript运行时（QuickJS）在垃圾回收时触发断言失败。

问题现象

当执行包含以下代码的脚本时：

const hasContentType = new Request('', {
    body: new ReadableStream(),  // 问题触发点
    method: 'POST',
    get duplex() {
      return 'half';
    },
}).headers.has('Content-Type');

运行时会在程序退出时抛出断言错误：

Assertion failed: (list_empty(&rt->gc_obj_list)), function JS_FreeRuntime, file quickjs.c, line 2141.

这个错误表明在运行时关闭时，垃圾回收器（GC）的对象列表中仍然存在未被正确释放的对象。

技术分析

底层机制

1. QuickJS的垃圾回收机制：QuickJS使用标记-清除（Mark-and-Sweep）算法进行内存管理。所有JavaScript对象都需要正确标记，以便GC能够识别和回收。

2. Rust与QuickJS的交互：LLRT通过Rust绑定使用QuickJS，需要确保Rust层创建的所有JavaScript对象都正确注册到GC系统中。

3. 流式API的特殊性：ReadableStream属于Web Streams API，其实现在底层可能涉及复杂的资源管理，包括背压控制、数据缓冲等。

问题根源

经过开发者深入分析，发现问题出在Rust与QuickJS绑定层对ReadableStream相关API的处理上：

1. GC标记缺失：创建ReadableStream对象时，没有正确设置GC跟踪标记。

2. 资源泄漏：底层实现中可能遗漏了对某些内部资源的释放处理。

3. 生命周期管理：当ReadableStream作为Request对象的body时，其生命周期管理变得更加复杂。

解决方案

项目维护者确认这是一个内存泄漏问题，并提出了修复方向：

1. 补充GC跟踪：为Stream API添加必要的GC标记代码，确保所有相关对象都能被垃圾回收器正确识别。

2. 完善资源释放：检查并完善ReadableStream相关资源的释放逻辑。

3. 边界条件测试：增加对特殊使用场景（如作为Request body）的测试用例。

技术启示

1. 跨语言交互的复杂性：当JavaScript运行时通过其他语言（如Rust）实现时，内存管理需要特别小心。

2. GC敏感API的开发：实现可能被垃圾回收的对象时，必须确保完整的GC集成。

3. 断言的价值：QuickJS在运行时关闭时检查GC列表的断言，帮助开发者及早发现了内存泄漏问题。

总结

这个问题展示了JavaScript运行时底层实现的复杂性，特别是在处理现代Web API如ReadableStream时。通过分析这类问题，我们可以更好地理解：

• 垃圾回收机制在实际项目中的重要性
• 跨语言绑定的潜在陷阱
• 流式API的特殊内存管理需求

对于LLRT这样的轻量级运行时项目，正确处理这类底层问题对保证项目稳定性和可靠性至关重要。开发者社区通过协作快速定位并解决问题，展现了开源项目的优势。