Tarantool IPROTO触发器内存泄漏问题分析与修复

在分布式数据库系统Tarantool中，开发者发现了一个与IPROTO协议触发器相关的内存泄漏问题。这个问题会导致系统在特定条件下持续消耗内存，最终触发操作系统的OOM Killer机制终止进程。

问题背景

内存泄漏发生在使用IPROTO协议覆盖触发器时。具体场景是当用户通过net.box模块建立连接并频繁执行eval操作时，系统内存会不断增长而得不到释放。这个问题最早出现在3.1.0版本的某个中间开发版本中，并持续影响到后续版本。

问题复现

开发者提供了一个简洁的复现脚本：

local net = require('net.box')
local trigger = require('trigger')

box.cfg{listen = 3301}
box.schema.user.grant('guest', 'super', nil, nil, {if_not_exists = true})
trigger.set('box.iproto.override.eval', '1', function()
    return false
end)

local conn = net.connect(3301)
local s = string.rep('x', 512 * 1024)
while true do
    conn:eval('return 1', {s})
end

这个脚本会：

1. 配置Tarantool监听3301端口
2. 设置一个IPROTO eval操作的覆盖触发器
3. 建立连接并不断发送包含512KB大字符串的eval请求

在运行几分钟后，系统内存就会被耗尽，最终触发OOM Killer终止进程。

技术分析

内存泄漏的根本原因在于IPROTO触发器处理逻辑中的资源释放不完整。当设置IPROTO覆盖触发器时，系统需要正确处理请求和响应的内存管理。在当前的实现中，某些情况下请求数据的内存没有被正确释放，特别是在触发器返回false拒绝请求时。

这个问题特别值得关注的是：

1. 每次eval请求都携带大量数据（512KB）
2. 触发器直接返回false，不处理实际请求
3. 请求数据在拒绝后没有被释放
4. 高频请求下内存迅速积累

解决方案

开发团队通过以下方式修复了这个问题：

1. 完善IPROTO触发器的内存管理机制
2. 确保在触发器拒绝请求时正确释放相关资源
3. 添加了相关的测试用例防止回归

修复的核心是确保无论触发器如何处理请求（接受或拒绝），所有分配的资源都能被正确释放，避免内存泄漏。

影响范围

这个修复对以下情况特别重要：

1. 使用IPROTO覆盖触发器的应用
2. 处理大量数据请求的场景
3. 需要长期稳定运行的服务

最佳实践

为避免类似问题，开发者应该：

1. 定期检查内存使用情况
2. 对自定义触发器进行压力测试
3. 关注Tarantool的版本更新和修复
4. 在开发环境中使用内存检测工具（如ASAN）

这个修复已经合并到主分支，并将包含在后续的稳定版本中，建议用户及时更新以获得更稳定的内存表现。