Re: LuaJIT2 crashes with luabind or wxLua

[Mike Pall <mikelu-1004@...>]

Daniel Wallin wrote:
> > For luabind this means: you may want to remove all problematic
> > uses of RAII. Compile in debug mode and check the disassembly for
> > all references to fs:[0] that are not caused by explicit try/catch
> > constructs.
> 
> That's certainly possible to do, lua_error() is only called in a handful
> of places.

It's not just lua_error(). A lot of lua_* API functions can
implicitly throw an error (see the manual).

> This *does* work in plain Lua though, where lua_error() is
> explicitly specified to perform a longjmp().

Since we're talking about Windows/x86, Microsoft's official
statement wrt. mixing C++ and longjmp is here:

  "Do not use setjmp and longjmp in C++ programs."
  http://msdn.microsoft.com/en-us/library/yz2ez4as(vs.71).aspx

MSVCRT's longjmp seems to do some clean up, but that's an
implementation detail. All bets are off if you compiled Lua with
MinGW.

[And regarding LuaJIT: I can't do anything about it. I can't use
longjmp directly and the SEH patent prevents me from adding
interoperability with SEH exception handling.]

> The use of longjmp() as in my example is well defined:
> 
>   18.7.4:
> 
>   If any automatic objects would be destroyed by a thrown exception
>   transferring control to another (destination) point in the program, then
>   a call to longjmp(jbuf, val) at the throw point that transfers control
>   to the same (destination) point has undefined behavior.

Umm? It certainly explicitly says what's undefined. But nowhere
does it claim what _is_ defined. E.g. MSVC effectively hoists the
implicit try/catch around RAII to the top of the function. Both in
theory and practice, longjmp() and C++ exceptions do NOT mix well.

--Mike