Re: LuaJIT2 crashes with luabind or wxLua

[Daniel Wallin <daniel@...>]

On Fri, Apr 16, 2010 at 03:32:15PM +0200, Mike Pall wrote:
> Daniel Wallin wrote:
> > The key is the std::string object in throw_error(). Without that
> > everything works fine, with it present the throw crashes. Any ideas?
> 
> Oh yes, that explains it all. :-)
> 
[snip good explanation]
> LuaJIT 2.0 on x86 uses internal frame unwinding. It will crash on
> Windows/x86, since the SEH chain is corrupted. It doesn't call
> destructors and may cause a memory leak on all other x86 platforms.
> There's an undocumented option to use external frame unwinding on
> x86 (non-Windows), but you need to read src/lj_err.c carefully.
> 
> LuaJIT 2.0 on Windows/Linux/OSX x64 uses external frame unwinding,
> so all destructors are called. You can safely use RAII and freely
> mix Lua errors with C++ exceptions.
> 
> Summary: avoid all kinds of RAII in C++ code if any Lua error
> might be thrown from the same call frame or any inner frames. This
> is particularly nasty to debug for implicit errors (like luaL_*
> type checks that rarely fail). You'll only notice this when the
> _next_ C++ exception is thrown. Alternatively get everyone to
> upgrade to an x64 OS. :-)
> 
> 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. This *does* work in plain Lua though, where lua_error() is
explicitly specified to perform a longjmp(). 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.

-- 
Daniel Wallin
BoostPro Computing
http://www.boostpro.com