Re: Possible bug in Lua's Garbage Collector

["Patrick Donnelly" <batrick.donnelly@...>]

On Thu, May 29, 2008 at 5:42 AM, Luiz Henrique de Figueiredo
<lhf@tecgraf.puc-rio.br> wrote:
>> showing this problem. I haven't been able to yet, however I did get
>> some sort of memory leak while try to reproduce the above
>
> I haven't tried to follow the logic of your example, but I don't think it
> qualifies as a memory leak because if you call lua_close(L) at the end of
> main then all udata are finalized. So, no memory is leaked.

I recompiled with LUA_USE_APICHECK and added a checkstack() I forgot
after adding 1000 tables to the stack (where the assertion failed).
the problem still exists. As I understand it, everything on go()s
stack should be collected after returning and lua_gc(L LUA_GCCOLLECT,
0); is called? It is not?

> Also, if you build Lua with LUA_USE_APICHECK on (just #define it in luaconf.h),
> then you'll get an assertion raised very soon:
>        % ./a.out
>        Entering go
>        making userdata:0x805df2c
>        a.out: lapi.c:232: lua_pushvalue: Assertion `L->top < L->ci->top' failed.
> This is raised by lua_pushvalue(L, 2) just after the loop that creates
> tables So, it seems to me there's a stack overflow there. However, this
> overflow is not the culprit because changing 1000 in luaL_checkstack to
> 1200 does not give the results you expected.
>
> After a bit of digging, the problem seems to be that go leaves the
> threads in the stack, and their memory is never collected. That's why
> settop to 0 solves the problem.

That sounds like a problem?

I don't see why Lua is collecting the userdata in my Nmap code as it
is clearly still on the stack (at index 1). I feel these problems may
be related.

-- 
-Patrick Donnelly

"One of the lessons of history is that nothing is often a good thing
to do and always a clever thing to say."

-Will Durant