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

[Tacvek]

----- Original Message ----- 
From: "Ronald Lamprecht" <address@hidden>
To: "Tacvek" <address@hidden>
Cc: "Daniel Heck" <address@hidden>; <address@hidden>
Sent: Friday, June 30, 2006 7:01 AM
Subject: Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows


> HI,
>
> Tacvek wrote:
> > Damnit.
> > The bug seems like it must be elsewhere. Yet that backtrace really 
> > strongly implied an error in the compiler's exception handler.
> > I mean that backtrace definately showed a crash in that second of the 
> > code, and the way gdb seemed to skip over Enigma's code,
> > also seemed to fit.
>
> 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.


> 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.
>
> > Now instead of silently crashing, I get this messagebox:
> >
> > ---------------------------
> > Microsoft Visual C++ Runtime Library
> > ---------------------------
> > Runtime Error!
> >
> > Program: C:\Program Files\Enigma\enigma.exe
> >
> > This application has requested the Runtime to terminate it in an unusual 
> > way.
> > Please contact the application's support team for more information.
> >
> >
> > ---------------------------
> > OK
> > ---------------------------
> >
> > I guess that is progress.
> >
> > Damn Windows!
>
> Please take the SDL parachute into account that catches fatal signals! I 
> guess it tries to switch back the screen resolution and to give back the 
> system the control over the grabbed mouse before terminating the app in 
> case of errors. You can experiment with the wizard mode that should switch 
> off the parachute.

Well, that is a good point. Nevertheless, the fact that I get an error 
message now
rather than termination or true crash indicates that something is happening 
differently.
Either the two exception handling meathods have different implentation 
meathods for terminate(),
or one meathod results in a terminate, and the other is relying on the SDL 
parachute.

I'm never getting parchute deployment notices is stderr.txt like I normally 
do with enigma crashes.

However with wizard mode, the slsj-exception handler causes a true dr. 
Watson GPF notification dialog.
The other exception handler gives me that unusual dialog box regardless.

So it seems like the crash with the slsj method is being caught by SDL, but 
I still can't
guess why SDL is not printing a parachute deployment notice to stderr.txt

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.



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.


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.