Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows

[Ronald Lamprecht]

Hi,

Tacvek wrote:
> > The "end" of gdb stepping at lobject.c:166 is another "problem" - I 
> > succedded to stepi at that line. After the function is called I can 
> > step again through the code until the world.cc throw statement in 
> > either case. (No idea why step doesn't gain back control automatically).
>
> Is the lua interpreter running as a seperate thread? That would explain 
> why stepping would pause untill the next lua run.
> It is imposible to step through the code of a suspended thread for 
> obvious reasons.

No lua runs in the same thread.

> > I can stepi into the throw code and the fault occurs somewhere in the 
> > gcc internal libraries. It is always about 3000 stepi from the throw 
> > code, but not at a deterministic position! An interersting fact is 
> > that always some hundred stepi before the crash the sound from the 
> > Enimga st-switch is emitted - obviously by another thread. Still no 
> > idea how exceptions, threads and a special selection of luaL_error 
> > calls crash the system.
>
> Let us assume this "usual termination" dialog indicates a call to 
> terminate().
> This means that there is a bug in slsj causing it to crash because the 
> exception is not caught.
> The other meathod is calling terminate because the exception is not caught.

Remember that I always saw a segmentation fault in stepping through the 
slsj code. An uncaught execption should behave in another way. Enigmas 
main.cc catches all exceptions eihterway (l.644).

> Then why on earth is the exception not getting caught? There is 
> definately a catch statement that applies part way up the backtrace.
>
> Wait a second. Just a guess: The exception being thrown is NOT the one 
> normally thrown by that line. Lua is probably returning an error, but 
> for some reason the error message is not a normal null termated string. 
> That may cause the lua::LastError function to throw an exception.
> Try setting a breakpoint in lua:: LastError and stepping past the first 
> line, and then calling "lua_tostring (L, -1)"and examining the result in 
> gdb.
> If it looks like garbage then that is probably our problem. I would not 
> be surprised that string() would toss an exception if it was fed garbage.
> Or a slightly easier way to test this is to add a extra catch clause to 
> game::StartGame that catches all exceptions.
> If that is triggered then obviously it is not an 
> enigma_levels::XLevelRuntime exception that is being thrown.

As I feared possible trouble in this area I replaced the world.cc throw 
statement by

> throw enigma_levels::XLevelRuntime("world callback error\n");

during all my stepping tests. Thus there is no one else to throw foreign 
exceptions.

> If that does pan out, then we are back to square one, but at least we 
> can be fully confident that the error is in the Lua code, and not in 
> Enigma.

I am very confident that the bug is not located in Enigma. But I still 
have no idea whether it is Lua or Mingw gcc that causes the trouble.

A mingw gcc 3.4.5 - DW2 test would be interesting.

- Ronald