Re: Lua 5.1 (work1) now available

["Adam D. Moss" <adam@...>]

Very exciting. :)  However, I experience a crash some way deep
into my lua-heavy apps (which work with lua 5.1w0 and 5.0.x).

Program received signal SIGSEGV, Segmentation fault.
luaH_getstr (t=0x829f448, key=0x829bac0) at ltable.c:421
421         if (ttisstring(gkey(n)) && rawtsvalue(gkey(n)) == key)
(gdb) bt
#0  luaH_getstr (t=0x829f448, key=0x829bac0) at ltable.c:421
#1  0x0829f448 in ?? ()
(gdb) print n
$1 = (struct Node *) 0x21
(gdb) print *n
Cannot access memory at address 0x21
(gdb) print *key
$2 = {dummy = {u = 2.0004959106445312, s = 0x0, l = 0}, tsv = {next = 0x0, tt 
= 4 '\004', marked = 1 '\001',
    reserved = 0 '\0', hash = 3633474071, len = 16}}
(gdb) print *t
$3 = {next = 0x829e7f0, tt = 6 '\006', marked = 1 '\001', flags = 0 '\0', 
lsizenode = 1 '\001',
  metatable = 0x81bd738, array = 0x829a3a8, node = 0x5, firstfree = 
0x82b1670, gclist = 0x0, sizearray = 136931696}

That's probably a symptom of something else.  I haven't tried
defining lua_assert() (or whatever it is in 5.1) yet.

I've tried compiling my apps differently (luac -s, and the C app-core with
all its assertions turned off and optimization turned on) and some of them
do run (others crash in a different, later place).  When they run, though,
I notice that the value returned by collectgarbage("count") is about 2.5x
as large as it was in work0; my heaviest lua-using app crashes early so I
can't comment on any speed/memory/smoothness improvements there,
unfortunately.

Of course, this could all be because I'm still using the work1 Lua API
in the same way as work0, and something critical might have semantically
changed which Roberto has yet to mention. :)

Let me know if there's more I can do to help.

Thanks,
--Adam