Lua内存泄漏在C进程中。

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

尽管我尝试使用 lua_gc() 来获取并控制 Lua 的内存使用情况,但 C 进程的内存使用仍然很高。即使 Lua 表示只使用了 4MB 的内存,但 C 进程使用了超过 150MB 的内存。

我还尝试使用我的 l_alloc() 函数来追踪 Lua 的内存分配情况,但通过调用 lua_gc(LUA_GCCOUNT) 和 lua_gc(LUA_GCCOUNTB) 得到的内存使用情况与 Lua 提供的内存使用情况是相同的。

调用 lua_close() 关闭 Lua 环境后,进程内存下降,看起来正常。因此,我认为“丢失的内存”仍然由 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

输出告诉我,在 GC 后 Lua 的内存使用量下降了,但通过持续检查 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 程序的内存使用量?

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

点赞
用户200540
用户200540

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

2013-08-08 06:57:19