[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT2 crashes with luabind or wxLua
- From: Mike Pall <mikelu-1004@...>
- Date: Thu, 15 Apr 2010 21:20:23 +0200
Daniel Wallin wrote:
> On Thu, Apr 15, 2010 at 02:17:23PM +0200, Mike Pall wrote:
> > It could be that luabind tries to throw exceptions across Lua
> > frames or tries to throw Lua errors across C++ frames protected
> > with try/catch (works on Windows/x64, crashes on Windows/x86).
> It doesn't. In this case static_class_gettable() calls lua_error()
> directly, with no non-trivial objects alive on the stack, so it should
> be longjmp-safe. lua_pcall() returns properly, and then the crash
> happens when luabind throws an exception.
Ok, so the luabind DLL rethrows the pcall() error as a C++
exception. And the try/catch in main.cpp (in the EXE) ought to
catch it. There's no other call frame inbetween, so how can that
Maybe this is just another instance of the cross-module exception
throwing problem on Windows? The general recommendation seems to
be to avoid this at all cost. Apparently many things can go wrong:
exception destructor uses a different memory allocator, different
compiler flags, debug vs. release mode compiles, ...
As far as I can see from the comments in the code, the first error
(for the invalid member) works, only the second error (for the
invalid static member) ought to cause a crash on Windows/x86 (do
you see this, too?).
That's remarkable, because the only difference is from where the
original error is thrown. Either from lj_meta_call() (for the call
of a nil value) or in static_class_gettable() -- but both end up
in the exact same code path. And your analysis indicates that it
crashes later on the rethrow. Maybe this is order-sensitive? Maybe
the free list of the memory allocator got corrupted?
> FWIW I can reproduce this on my Windows VM, but I have no idea what's
What does WinDbg say? Single-stepping the machine code between the
throw and the catch might be informative, too.