5.1w1 aborts

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

Hi!

I've done some more digging around looking for my app's
crashes when using 5.1work1, which I mentioned a week or
so ago.  (The application works well in Lua 5.0.1, 5.0.2,
and 5.1work0.)

This time I enabled lua_abort() and (thankfully) I now
get Lua aborts consistantly from two call-sites, instead of
assorted crashes.  The first site consistantly aborts on this line:

local mt = getmetatable(getfenv());

... unfortunately that's not enough alone to reproduce it.  This
happens as part of my protection of the globals table, where
the global table has a metatable applied to it to catch (and
error upon) __index and __newindex; I then repeatedly unprotect
and re-protect the globals table as needed by adding and removing
its metatable, and it's only after doing this a few times that I
get the abort (from, I imagine, checkliveness()):

#2  0x4017cbf8 in abort () from /lib/libc.so.6
#3  0x080e0378 in lua_getmetatable (L=0x81cbb48, objindex=1) at lapi.c:558
#4  0x080f5bd9 in luaB_getmetatable (L=0x81cbb48) at lbaselib.c:94
#5  0x080e35ae in luaD_precall (L=0x81cbb48, func=0x82f6f8c, nresults=1) at 
ldo.c:282
#6  0x080eff53 in luaV_execute (L=0x81cbb48, nexeccalls=4) at lvm.c:592
#7  0x080e37e9 in luaD_call (L=0x81cbb48, func=0x81d8b48, nResults=0) at 
ldo.c:339
#8  0x080e0982 in f_call (L=0x81cbb48, ud=0xbfffeb90) at lapi.c:729
#9  0x080e2a62 in luaD_rawrunprotected (L=0x81cbb48, f=0x80e0960 <f_call>, 
ud=0xbfffeb90) at ldo.c:87
#10 0x080e3d4a in luaD_pcall (L=0x81cbb48, func=0x80e0960 <f_call>, 
u=0xbfffeb90, old_top=576, ef=564) at ldo.c:438
#11 0x080e0a06 in lua_pcall (L=0x81cbb48, nargs=0, nresults=0, errfunc=-2) at 
lapi.c:750
#12 0x080623a9 in zlua_pcall (state=0x81cbb48, nargs=0, nresults=0) at zlua.c:56
[...]
(gdb) frame 3
#3  0x080e0378 in lua_getmetatable (L=0x81cbb48, objindex=1) at lapi.c:558
558         sethvalue(L, L->top, mt);
(gdb) print *L
$1 = {next = 0x0, tt = 8 '\b', marked = 32 ' ', top = 0x82f6fa4, base = 
0x82f6f98, l_G = 0x81cbba4, ci = 0x82d08d8,
  stack_last = 0x82f74a8, stack = 0x82f6c80, stacksize = 180, end_ci = 
0x82d0950, base_ci = 0x82d07d0, size_ci = 16,
  nCcalls = 3, hookmask = 0 '\0', allowhook = 1 '\001', isSuspended = 0 
'\0', basehookcount = 0, hookcount = 0,
  hook = 0, _gt = {tt = 5, value = {gc = 0x81cbaf0, p = 0x81cbaf0, n = 
6.7242626885855993e-316, b = 136100592}},
  openupval = 0x0, gclist = 0x0, errorJmp = 0xbfffea60, errfunc = 564}
(gdb) print *L->top
$2 = {tt = 5, value = {gc = 0x82bd658, p = 0x82bd658, n = 
-1.9962463683308638, b = 137090648}}
(gdb) print *mt
$3 = {next = 0x82b1858, tt = 5 '\005', marked = 1 '\001', flags = 2 '\002', 
lsizenode = 1 '\001', metatable = 0x0,
  array = 0x0, node = 0x82af8f0, firstfree = 0x82af8f0, gclist = 0x82b9ca8, 
sizearray = 0}


Now onto the second abort site.  :)  If I disable the global-protection
stuff above, I get a later (but still consistant) abort after a few
seconds of normal app activity:

#2  0x4017cbf8 in abort () from /lib/libc.so.6
#3  0x080eedd1 in luaV_execute (L=0x81cbb48, nexeccalls=1) at lvm.c:435
#4  0x080e37e9 in luaD_call (L=0x81cbb48, func=0x874bb48, nResults=1) at 
ldo.c:339
#5  0x080e0982 in f_call (L=0x81cbb48, ud=0xbffff320) at lapi.c:729
#6  0x080e2a62 in luaD_rawrunprotected (L=0x81cbb48, f=0x80e0960 <f_call>, 
ud=0xbffff320) at ldo.c:87
#7  0x080e3d4a in luaD_pcall (L=0x81cbb48, func=0x80e0960 <f_call>, 
u=0xbffff320, old_top=192, ef=180) at ldo.c:438
#8  0x080e0a06 in lua_pcall (L=0x81cbb48, nargs=1, nresults=1, errfunc=-3) at 
lapi.c:750
#9  0x080623a9 in zlua_pcall (state=0x81cbb48, nargs=1, nresults=1) at zlua.c:56
[...]
(gdb) frame 3
#3  0x080eedd1 in luaV_execute (L=0x81cbb48, nexeccalls=1) at lvm.c:435
435             setobj2s(L, ra, cl->upvals[b]->v);
(gdb) print *L
$1 = {next = 0x0, tt = 8 '\b', marked = 32 ' ', top = 0x874bc5c, base = 
0x874bb54, l_G = 0x81cbba4, ci = 0x82972f8,
  stack_last = 0x874c2b0, stack = 0x874ba88, stacksize = 180, end_ci = 
0x8297460, base_ci = 0x82972e0, size_ci = 16,
  nCcalls = 1, hookmask = 0 '\0', allowhook = 1 '\001', isSuspended = 0 
'\0', basehookcount = 0, hookcount = 0,
  hook = 0, _gt = {tt = 5, value = {gc = 0x81cbaf0, p = 0x81cbaf0, n = 
6.7242626885855993e-316, b = 136100592}},
  openupval = 0x0, gclist = 0x0, errorJmp = 0xbffff1f0, errfunc = 180}
(gdb) print ra
$2 = (struct lua_TValue *) 0x874bb6c
(gdb) print *ra
$3 = {tt = 5, value = {gc = 0x892a868, p = 0x892a868, n = 
7.106101520600265e-316, b = 143829096}}
(gdb) print *cl
$4 = {next = 0x8326868, tt = 6 '\006', marked = 4 '\004', isC = 0 '\0', 
nupvalues = 6 '\006', gclist = 0x8326970,
  p = 0x82fff50, g = {tt = 5, value = {gc = 0x82965b8, p = 0x82965b8, n = 
6.7652776469882395e-316, b = 136930744}},
  upvals = {0x8326718}}
(gdb) print *cl->upvals[b]
$5 = {next = 0x8326718, tt = 10 '\n', marked = 0 '\0', v = 0x832689c, value = 
{tt = 5, value = {gc = 0x892a868,
      p = 0x892a868, n = 7.106101520600265e-316, b = 143829096}}}
(gdb) print *cl->upvals[b]->v
$6 = {tt = 5, value = {gc = 0x892a868, p = 0x892a868, n = 
7.106101520600265e-316, b = 143829096}}

This is a C->lua code path that's already been trodden several times by
this point in the app; at the moment I don't know what, on the lua side,
is causing the fatality this time around.

Note that I've applied the patch for the '...' crasher (I was encountering
these problems before, and I don't explicitly use the new '...', but I
patched just in case).

I've been trying and failing to make a small testcase for the first
problem.  I'll persist some more, then look into the second.

Regards,
--Adam