RE: garbage colleciton crash

["Virgil Smith" <Virgil@...>]

Roberto already mentioned memory corruption which is a very good possibility
in this case.
However, given that your crash dumped stacked indicates failure in a call to
free you should also list linkage and threading errors as possible causes.

If the static/dynamic linkage in your application build/run process results
in linking to two separate copies of Lua (and thereby two separate copies of
the C run-times), or perhaps for some other reason causes linkage to two
different copies of the C run-time then you are very likely to get a crash
in free (as one C run-time instance attempts to free an object allocated
from the heap of another instance).

Thread safety problems in your application could result in heap corruption
and give similar problems.  Note, I am referring to thread safety on the C
side, not Lua co-routines/thread objects.

Good Luck

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Brett Bibby
Sent: Thursday, March 04, 2004 4:37 AM
To: Lua List
Subject: garbage colleciton crash


Hello,
We have been chasing a really bizarre bug all day. Undoubtedly it is in our
code and not Lua, but I''m hoping someone familiar with the Lua garbage
collector could help me understand the likely cause so I can try and find
the bug in our code. We crash in either one of two places (lua 5).

call to lua_setgcthreshold(L,0)
Crash A call stack:
>luaC_collectgarbage
>luaC_sweep
>sweeplist
>freeobj
>luaH_free
>luaM_realloc
>free (crashes in here in the pool manager of MSL by Metrowerks)

call to lua_setgcthreshold(L,0)
Crash B call stack:
>luaC_collectgarbage
>mark
>propagatemarks
>traversetable (crashes on line 181: if(!ttisnil(gval(n))) and n is NULL
after working down from index 510 to 0)

Here is the funny thing. I can get rid of the bug by slowly eliminating
lines of lua source code until I can get it down to a single ascii character
is the reason for the crash. For example, I can find the spot where:

test = 1 -- this will crash

I remove _one_ single ascii character from _anywhere_ in the file so the
file is simply one byte shorter...

tes = 1 -- this won't crash
tst = 1 -- this won't crash either
tsts = 1 -- now it crashes again

I checked the chunk reader and everything and it works fine with hundreds of
lines of scripts, functions, tables, etc.  I also have many MB of free RAM
available and I tried malloc'ing a huge block after the non-crash one and
that works fine too.  Is there any tips on debugging the gc anybody could
share?

Thanks,
Brett