lua-users home
lua-l archive

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

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
go wrong?

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
> wrong.

What does WinDbg say? Single-stepping the machine code between the
throw and the catch might be informative, too.