Manticore Search 内存泄漏问题分析与修复

问题背景

在 Manticore Search 7.0.0 版本中，开发人员发现了一个内存泄漏问题。这个问题出现在执行包含 JOIN 操作的 SQL 查询时，特别是在处理动态数据时未能正确释放内存。

问题重现

通过以下 SQL 测试用例可以重现该内存泄漏问题：

-- 创建测试表
create table x ( id bigint, j json );
create table y ( id bigint, j json );

-- 插入测试数据
insert into x values (1, '{"t":"d"}');
insert into y values (1, '{"t":"e"}');

-- 强制刷新内存块
flush ramchunk x;
flush ramchunk y;

-- 触发内存泄漏的查询
select to_string(y.j.t) as table2, concat(to_string(j.t), table2) as test 
from x join y on x.id = y.id order by test asc;

-- 清理测试表
drop table x;
drop table y;

问题分析

Valgrind 内存检测工具报告显示，在执行上述查询时存在内存泄漏。泄漏发生在 JoinSorter_c::PushJoinedMatches 函数中，具体是在调用 CalcContextItems 函数处理动态数据时。

核心问题在于：

1. 当生成动态数据时，系统会检查 IsDataPtrAttr() 属性
2. 如果该属性为真，应该调用 FreeDataPtr() 来释放内存
3. 但在当前情况下，这个释放操作没有被正确执行

技术细节

问题主要出现在 src/joinsorter.cpp 文件的 PushJoinedMatches 函数中。该函数负责处理 JOIN 操作的结果集合并推送到匹配排序器中。在处理过程中，它会：

1. 设置表达式计算的 blob 池
2. 复制动态属性数据
3. 重新打包 JSON 字段
4. 计算上下文项（这里发生内存泄漏）
5. 评估混合过滤器
6. 推送匹配结果

内存泄漏发生在计算上下文项的阶段，特别是当处理动态生成的字符串数据时，系统未能正确跟踪和释放这些内存。

解决方案

修复方案的核心是确保所有动态分配的内存都能被正确释放。具体措施包括：

1. 在处理动态数据时严格遵循所有权原则
2. 确保所有通过 IsDataPtrAttr() 检查的数据指针都能被 FreeDataPtr() 释放
3. 在适当的位置添加内存释放逻辑

修复后的代码正确处理了动态数据的生命周期，避免了内存泄漏的发生。

总结

这个内存泄漏问题展示了在复杂查询处理中管理动态内存的挑战。Manticore Search 通过修复这个问题，提高了系统在处理 JOIN 操作时的内存管理可靠性。开发者在使用类似功能时应当注意：

1. 动态生成的数据需要明确的所有权管理
2. 字符串和 JSON 处理是内存泄漏的高风险区域
3. 定期使用内存检测工具验证系统稳定性

这个修复确保了 Manticore Search 在处理复杂查询时能够更加稳健地管理内存资源。