c - C进程中的Lua内存泄漏

Question

我有一个用 Lua 运行的 C 程序。

虽然我尝试使用lua_gc()来获取和控制Lua的内存占用，但C进程内存占用仍然很高。 C 进程使用超过 150MB 内存，即使 Lua 说它只使用 4MB 内存。

我也尝试使用我的 l_alloc() 函数来跟踪 Lua 内存分配，但结果与通过调用 lua_gc(LUA_GCCOUNT) 和 lua_gc(LUA_GCCOUNTB) 告知的 Lua 内存使用情况相同。

调用lua_close()关闭Lua环境后，进程内存down了，看起来还好。 因此，我认为'丢失的内存'仍然是由Lua而不是C程序控制的。

这是示例 C 代码。 它创建一个 Lua 环境，调用 Lua 函数清除数据，然后检查内存使用情况。

int main()
{
    int rc;
    uint64_t gc_mem_usage;

    lua_State* Lua = luaL_newstate();
    luaL_openlibs(Lua);

    lua_gc(Lua, LUA_GCSTOP, 0);
    luaL_dofile(Lua, "test.lua");

    gc_mem_usage = ((uint64_t)lua_gc(Lua, LUA_GCCOUNT, 0) << 10) + lua_gc(Lua, LUA_GCCOUNTB, 0);
    printf("Lua mem usage: [%" PRIu64 "] Bytes\n", gc_mem_usage);

    lua_getglobal(Lua, "command_handler");
    lua_pushstring(Lua, "CC");
    rc = lua_pcall(Lua, 1, 0, 0);
    if (rc != 0 ) {
        printf("function error\n");
        return;
    }

    lua_settop(Lua, 0);

    // do full gc
    lua_gc(Lua, LUA_GCCOLLECT, 0);
    lua_gc(Lua, LUA_GCCOLLECT, 0); // I don't know why it has different result by calling full gc twice
    sleep(1);

    printf("-------------After GC ----------------------\n");
    gc_mem_usage = ((uint64_t)lua_gc(Lua, LUA_GCCOUNT, 0) << 10) + lua_gc(Lua, LUA_GCCOUNTB, 0);
    printf("Lua mem usage: [%" PRIu64 "] Bytes\n", gc_mem_usage);

    // infinite-loop
    while(1);
}

Lua示例代码:

local abc = {}

function command_handler(cmd)
    if (cmd == "CC") then
        abc = {}
    end
end

for i =0, 2000000 do
    abc[i] = "ABC" .. i .. "DEF"
end

输出:

Lua mem usage: [204913817] Bytes
-------------After GC ----------------------
Lua mem usage: [4219342] Bytes

输出告诉我 Lua 内存使用率在 GC 之后下降了，但是通过不断检查 atop，这个 C 进程的内存使用率仍然很高(193.7MB)。

 PID MINFLT MAJFLT      VSTEXT  VSIZE  RSIZE  VGROW  RGROW  MEM CMD     1/1
4622      1      0          3K 193.7M 183.9M     0K     4K  18% a.out

有什么解决办法可以减少C进程的内存占用吗？

我的环境是Lua 5.1.4，运行在Ubuntu/CentOS。

Answer 1

Lua 通过调用提供的释放函数(默认为 realloc(block, 0))忠实地释放无法访问的对象。看起来 libc 分配器正在努力返回未使用的内存，可能是由于高碎片。查看 strace 输出(我在 64 位 Debian 6 上得到与 Lua 5.1.4 大致相同的数字)，C 运行时选择使用 brk 分配小递增，但随后没有释放(调用 brk 具有较低的值)。但是，如果您在进入无限循环之前插入 malloc_trim(M_TOP_PAD)，您将在 top 输出中看到驻留大小急剧下降到 ~5M 和 strace 显示数据段确实被 brk 修剪了。在这种情况下，使用自定义分配器(例如基于池的分配器)或调整 malloc 参数可能会有所帮助。