[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT 2.0.0-beta5: Strange crash (probably my fault but ..)
- From: Mike Pall <mikelu-1101@...>
- Date: Mon, 24 Jan 2011 19:56:43 +0100
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004790cc in lj_BC_RET ()
The most likely cause for this is an immediately preceding call to
a C function from your Lua code. If this call returns an undefined
or bad value (e.g. more than it pushes on the stack), it'll mess
up the internal Lua stack, which may lead to a crash later on.
> I do multiple lua calls from my C code but it always fails in that
> spot, the only difference I can see is that I get one return whereas in
> others I get none.
The problem is unlikely to be in the caller. The problem is in the
C code you call from Lua.
> I can not paste the whole lua source as the game is several thousand
> files, but I see no obvious reasons this can fail (and not fail in
> standard lua 5.1.4).
Sadly, I'm not a clairvoyant. You'd need to narrow it down to the
Lua code that's executing immediately before the crash. Then have
a close look at the C functions that are called there.
The other suggestion is to recompile Lua with assertions turned on.
Then test your code with it and fix all problems you may
encounter. Only then switch to LuaJIT, optionally recompiled with
assertions turned on (see src/Makefile). Don't forget to turn off
the assertions for performance testing or deployment.
> For reference, my docall method is as follow, nothing fancy:
Not spectacularly efficient code, but I guess this doesn't matter
much here. Remember that lua_pushcfunction() allocates memory for
a new closure, each time you run it. I guess it would be better to
use debug.traceback as an error handler, anyway.
> int base = lua_gettop(L) - narg; /* function index */
You might want to add your own assert(base > 0) here.