segfault due to throwing in panic handler

[MartinNowak]

import luad.all;

void main()
{
    auto lua = new LuaState;
    lua.doString("func()");
}

Stack unwinding doesn't work reliably from the panic handler as it requires C-like stacks and -fno-omit-frame-pointer for the interpreter.

[JakobOvrum]

I have a few test cases reproducing this one for my system, but it depends on the DLL you link to; the code you provided works fine for me for example.

It's a pretty serious issue though and I'm not sure how to best fix it. Porting all of Lua to D is one option. I suppose recompiling the Lua DLL with the proper flags is another option?

[MartinNowak]

For me that simple example works with LuaJIT but not with my installed Lua-5.1.4. For other examples it's vice versa.

As http://pgl.yoyo.org/luai/i/lua_atpanic says you may escape with a longjmp something along this line would work.

// untested
void* stacktop;
auto wrap_call(alias func, Args...)(auto ref Args args)
{
    asm { mov stacktop, ESP; }
    return func(args);
}

extern(C) void onPanic()
{
    asm { mov ESP, stacktop; }
    throw new Exception("");
}

void doString()
{
    ...
    wrap_call!lua_pcall(...);
}

After reading http://www.lua.org/pil/24.3.1.html I'm really wondering why it calls at_panic in the first place because it should be in protected mode.

[JakobOvrum]

@dawgfoto, the effort is to make it unroll the D stack on the way up.

If you use pcall, you don't get that. If you use xpcall, you can do the same as the panic function, but with the same problems.

[belm0]

Since this LuaD functionality has known problems I suggest disabling it by default and adding a compile or runtime option to enable.

[JakobOvrum]

Some more dialogue concerning this issue can be found at issue #40.

I hope we can keep it centralized here in the future.

[JakobOvrum]

I pushed Lua libraries for x86-32 and x86-64 Linux compiled with -fno-omit-frame-pointer, which works around this issue for those platforms. That also fixes the travis build and test run. It's also working for 32-bit Windows.

The D issue for this is 10671.

[TurkeyMan]

This issue has just drawn one of my projects to a crashing halt... what workarounds exist?

[TurkeyMan]

Why aren't we using pcall and catching the error there? Ideally, we could avoid the panic completely...

[JakobOvrum]

The issue is compiler and platform specific. The general fix is to compile Lua with frame pointers intact. Which platform/compiler targets do you have issues with?

[TurkeyMan]

I expect compiling with frame pointers intact would have a very high cost on performance... Right now I'm on Win-x86_64 MSVC2015 + DMD, but this is a cross-platform project, including intended Android/iOS builds. Perhaps if Lua is built with C++ exceptions support? Are there other known workarounds? SJLJ?