Re: Crash when calling C from a finalizer

[Gaspard Bucher <gaspard@...>]

On Thu, Dec 29, 2011 at 6:18 PM, Gé Weijers <ge@weijers.org> wrote:
> I noted that the lua_State used in the pcall is different from the one used
> to call the finalizer. Could you be using the wrong lua state (e.g. a stale
> thread's state?)
>
> Gé
>
>
> On Thu, Dec 29, 2011 at 9:01 AM, Gaspard Bucher <gaspard@teti.ch> wrote:
>>
>> On Thu, Dec 29, 2011 at 5:38 PM, Roberto Ierusalimschy
>> <roberto@inf.puc-rio.br> wrote:
>> >
>> > > I think it would be very valuable to have a comment on finalizers and
>> > > what
>> > > can be done in these in the reference manual. I lost a day's work
>> > > struggling with gdb to discover that calling any method from "C" from
>> > > a
>> > > finalizer is a bad idea (crash).
>> > >
>> > > [...]
>> > >
>> > > *29 – Managing Resources*
>> > > Life is not always that easy. [...]. This function can then release
>> > > any
>> > > resource associated with that userdatum *but it should not call a C
>> > > function from Lua*.
>> > >
>> > >
>> > > Or maybe the rule is slightly more complex. In my case, the crash
>> > > happens
>> > > with:
>> > >
>> > > Lua GC ---> Foobar::finalizer (custom C++ finalizer) --> pcall -->
>> > > call C
>> > > function
>> >
>> > There is no such restriction. You should be able to do whatever you want
>> > from a finalizer.
>> >
>> > -- Roberto
>> >
>>
>> Hi Roberto, thanks for the feedback. This means that my problem is
>> even more strange. The crash happens whatever C function I call. Here
>> is the gdb dump:
>>
>> #0  0x00000001018637c0 in ?? ()
>> Cannot access memory at address 0x1018637c0
>> #1  0x000000010003005e in luaV_execute (L=0x1005013c0, nexeccalls=4)
>> at lvm.c:590
>> #2  0x0000000100010b60 in luaD_call (L=0x1005013c0, func=0x1005015e0,
>> nResults=0) at ldo.c:377
>> #3  0x0000000100003847 in f_call (L=0x1005013c0, ud=0x7fff5fbff020) at
>> lapi.c:800
>> #4  0x000000010000f8a2 in luaD_rawrunprotected (L=0x1005013c0,
>> f=0x100003810 <f_call>, ud=0x7fff5fbff020) at ldo.c:116
>> #5  0x000000010001100e in luaD_pcall (L=0x1005013c0, func=0x100003810
>> <f_call>, u=0x7fff5fbff020, old_top=32, ef=0) at ldo.c:463
>> #6  0x000000010000391b in lua_pcall (L=0x1005013c0, nargs=1,
>> nresults=0, errfunc=0) at lapi.c:821
>> #7  0x00000001000f894c in lk::Finalizer::finalize (this=0x1005012b0)
>> at Finalizer.h:53
>> #8  0x00000001000f843b in Finalizer_destructor (L=0x1001009d0) at
>> Finalizer_core.cpp:39
>> #9  0x00000001000107fc in luaD_precall (L=0x1001009d0,
>> func=0x100803810, nresults=0) at ldo.c:319
>> #10 0x0000000100010b46 in luaD_call (L=0x1001009d0, func=0x100803810,
>> nResults=0) at ldo.c:376
>> #11 0x0000000100013f1f in GCTM (L=0x1001009d0) at lgc.c:467
>> #12 0x0000000100013f5a in luaC_callGCTM (L=0x1001009d0) at lgc.c:479
>> #13 0x000000010002260c in callallgcTM (L=0x1001009d0, ud=0x0) at
>> lstate.c:195
>> #14 0x000000010000f8a2 in luaD_rawrunprotected (L=0x1001009d0,
>> f=0x1000225f0 <callallgcTM>, ud=0x0) at ldo.c:116
>> #15 0x00000001000226e5 in lua_close (L=0x1001009d0) at lstate.c:209
>> #16 0x000000010002b1f1 in main (argc=2, argv=0x7fff5fbff3a0) at lua.c:389
>>
>> Not calling a C function works fine so I guessed this was the problem...
>>
>>                                                                Gaspard
>>
>
>
>
> --
> Gé
>

Hi Gé,

Thanks for the attentive reading, but the lua_State used is a lua
thread attached to the finalizer and it doesn't seem to be half-dead
since all Lua code runs fine. It's just C function calls that break.

I also tried the same scenario without using a different lua state but
I get the same result.

Ga