NaiveProxy 内存泄漏问题分析与解决方案

问题背景

NaiveProxy 是一款基于 Chromium 网络栈的网络工具，近期在 v128.0.6613.40-1 版本中，用户报告在特定环境下出现了内存持续增长且不释放的问题。这一问题在路由器等嵌入式设备上尤为明显，因为这些设备通常内存较小且需要长期运行。

问题根源分析

经过深入的技术调查，发现问题的核心在于 PartitionAlloc 内存分配器与 Linux 内核 madvise 系统调用的交互机制：

1. PartitionAlloc 的内存管理机制：Chromium 使用的 PartitionAlloc 内存分配器依赖 madvise 系统调用来高效管理内存，特别是用于释放不再使用的内存页。

2. 内核配置差异：某些嵌入式 Linux 发行版（特别是较旧版本）可能禁用了 CONFIG_ADVISE_SYSCALLS 编译选项，导致内核不支持 madvise 系统调用。

3. 三种构建方案对比：

   • 启用 PartitionAlloc 但不使用 madvise：会导致内存泄漏
   • 启用 PartitionAlloc 并使用 madvise：在不支持的内核上会崩溃
   • 禁用 PartitionAlloc：避免内存泄漏但牺牲性能

技术细节

在 Linux 内核中，madvise 系统调用允许应用程序向内核提供关于内存使用模式的建议，这对于高效的内存管理至关重要。Chromium 的 PartitionAlloc 利用这一机制来实现：

• 及时释放未使用的内存
• 优化内存布局
• 提高内存安全性

当内核不支持 madvise 时，PartitionAlloc 无法正确释放内存，导致内存使用量随时间持续增长。

解决方案演进

项目维护者经过多次迭代，最终确定了以下解决方案路径：

1. 初始方案：在静态构建中默认设置 no_madvise_syscall=true 以确保最大兼容性，但这导致了内存泄漏问题。

2. 临时方案：建议用户通过 ulimit 限制内存使用，并设置自动重启机制，但这只是权宜之计。

3. 最终方案：在静态构建中禁用 PartitionAlloc 和使用分配器垫片（use_partition_alloc=false use_allocator_shim=false），虽然这会降低在支持 madvise 的系统上的性能，但确保了在所有环境下的稳定性。

对用户的影响

1. 嵌入式设备用户：特别是使用旧版 OpenWrt（21.02.7 及更早版本）的用户，由于 musl 库版本限制，必须使用静态构建版本。

2. 性能权衡：在支持 madvise 的现代系统上，静态构建版本会有一定的性能损失；而在不支持 madvise 的系统上，则能保证内存稳定。

3. 版本选择建议：用户应根据自己的内核配置选择合适的版本，v130.0.6723.40-3 版本专门解决了这一问题。

最佳实践建议

1. 内核配置检查：用户应检查 /proc/config.gz 或 /boot/config-* 确认 CONFIG_ADVISE_SYSCALLS 是否启用。

2. 监控机制：对于关键业务环境，建议实现内存监控和自动重启机制。

3. 升级路径：尽可能升级到支持 musl time64 的新版系统（OpenWrt 22.03.0 及以上），以使用非静态构建版本。

总结

这一案例展示了在跨平台软件开发中，特别是在涉及底层系统调用的场景下，兼容性与性能之间的微妙平衡。NaiveProxy 通过灵活的构建配置，为不同环境的用户提供了可行的解决方案，同时也提醒我们在嵌入式系统开发中需要特别注意内核特性的差异。