lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Andrea wrote:
> The problem is that Visual Studio reports that the 2nd exception
> is unhandled and basically ignores it.
> This works fine with Lua (non jit).

Well, looks like the SEH chains got messed up on Windows/x86. :-(

Lua uses setjmp/longjmp from MSVC. Even though MSDN suggests that
mixing this with C++ exceptions is not safe, the longjmp from MSVC
cleans up the SEH chain. But I can't use setjmp/longjmp in LuaJIT.

As a workaround I tried manual unwinding of SEH chains, but that
didn't work at all. Neither does RtlUnwind() do the right thing on
x86 in this case. So I don't think I can provide an out-of-the-box
solution for this in LuaJIT.

> As soon as lua_error is in a function that contains try{}catch{}
> it fails. Mind you, lua_error is *outside* the try{}catch{},
> *not* in the catch, but still in the same function (like the
> link above).

MSVC optimizes functions with try/catch constructs by adding a
single SEH frame for the whole function. So even if you use
lua_error() outside of the catch, there's still an SEH frame
around it which needs to be cleaned up.

Your options are:
- Wrap the try/catch in a separate C++ function declared as
  __declspec(noinline). Call that from a function without
  try/catch and then run lua_error() from there.
- Use either Linux or Windows/x64 which have much better C++
  exception handling interoperability.