Runtime crash using LuaJIT

[Tylor Arndt]

I have tried using golua with LuaJIT 2.0.4 without success due to the unit tests crashing. I tired both static and dynamic lyncing and confirmed with ldd on the output of go test -c. As soon as I return to using standard Lua the tests pass. Here is an example crash while using dynamic linking:

fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x7fe7838180a0 pc=0x7fe7838180a0]

runtime stack:
runtime.throw(0x5da100, 0x2a)
    /home/user/go/src/runtime/panic.go:527 +0x90
runtime.sigpanic()
    /home/user/go/src/runtime/sigpanic_unix.go:12 +0x5a

goroutine 7 [syscall, locked to thread]:
runtime.cgocall(0x405c70, 0xc82002ddb0, 0x0)
    /home/user/go/src/runtime/cgocall.go:120 +0x11b fp=0xc82002dd68 sp=0xc82002dd38
tb/golua/lua._Cfunc_lua_pcall(0x40f11378, 0xffffffff00000000, 0x1, 0x0)
    ??:0 +0x39 fp=0xc82002ddb0 sp=0xc82002dd68
tb/golua/lua.(*State).pcall(0xc820010a40, 0x0, 0xffffffffffffffff, 0x1, 0x884060)
    /home/user/corp/src/tb/golua/lua/lua.go:182 +0x45 fp=0xc82002ddd8 sp=0xc82002ddb0
tb/golua/lua.(*State).callEx(0xc820010a40, 0x0, 0xffffffffffffffff, 0x1579001, 0x0, 0x0)
    /home/user/corp/src/tb/golua/lua/lua.go:201 +0xfb fp=0xc82002de48 sp=0xc82002ddd8
tb/golua/lua.(*State).Call(0xc820010a40, 0x0, 0xffffffffffffffff, 0x0, 0x0)
    /home/user/corp/src/tb/golua/lua/lua.go:214 +0x48 fp=0xc82002de80 sp=0xc82002de48
tb/golua/lua.(*State).DoString(0xc820010a40, 0x5a3900, 0x7, 0x0, 0x0)
    /home/user/corp/src/tb/golua/lua/lauxlib.go:106 +0x1c7 fp=0xc82002dee8 sp=0xc82002de80
tb/golua/lua.TestCheckStringFail(0xc82009c120)
    /home/user/corp/src/tb/golua/lua/lua_test.go:71 +0xbf fp=0xc82002df78 sp=0xc82002dee8
testing.tRunner(0xc82009c120, 0x8742d0)
    /home/user/go/src/testing/testing.go:456 +0x98 fp=0xc82002dfb0 sp=0xc82002df78
runtime.goexit()
    /home/user/go/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc82002dfb8 sp=0xc82002dfb0
created by testing.RunTests
    /home/user/go/src/testing/testing.go:561 +0x86d

goroutine 1 [chan receive]:
testing.RunTests(0x5eca30, 0x8742a0, 0xa, 0xa, 0x1)
    /home/user/go/src/testing/testing.go:562 +0x8ad
testing.(*M).Run(0xc82004fef8, 0xc82000a6c0)
    /home/user/go/src/testing/testing.go:494 +0x70
main.main()
    tb/golua/lua/_test/_testmain.go:72 +0x116

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /home/user/go/src/runtime/asm_amd64.s:1696 +0x1

[Alessandro Arzilli]

That error means that somewhere in a cgo call the program received a signal, usually SIGSEGV.
The test that is being executed there is a test that calls luaL_checklstring without putting anything on the stack to get lua to raise an error. That's where, instead of a lua error we receive a SIGSEGV, and that's what produces the stacktrace you are seeing.
I've checked the arguments I'm passing to lua and everything seems to be in order.
I have no idea why that code would produce a SIGSEGV on luajit but not on lua.

[Tylor Arndt]

@aarzilli Thanks- can you reproduce the failure when using LuaJIT? I'd like to rule out me doing something stupid before dive in and spend a lot of time working on a fix.

[Alessandro Arzilli]

Yes, specifically with version 2.0.2+dfsg-1 (the one that comes with Ubuntu 14.04.3), in case you are wondering.

[Tylor Arndt]

Thanks

[Demi Marie Obenour]

LuaJIT is much less tolerant of C API misuse than PUC-Lua. LuaJIT is designed first and foremost to be fast (which it is), and omits some checks. Note that the Lua manual requires the user to not violate the preconditions of its API, which are not checked.

Lua makes this harder by not providing an API to get the current stack size. The only options are (ugly, brittle, and error-prone) casting of pointer types (basically peeking into the guts of a lua_State)

Golua should do its own checks.