[Top][All Lists]

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

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

From: Tacvek
Subject: Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows
Date: Sat, 1 Jul 2006 20:00:52 -0400

----- Original Message ----- From: "Ronald Lamprecht" <address@hidden>
To: "Tacvek" <address@hidden>
Cc: <address@hidden>
Sent: Saturday, July 01, 2006 6:25 PM
Subject: Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows


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");

Good thinking.

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.

That is what I did compile the one that gives the unusual termination dialog box with.However I cross compiled, which for some reason seems to make it al but imposible to debug.

Lets see what we do know for sure:
* It looks like Enigma is throwing the XLevelRuntime, but for some reason Enigma's exception handlers are not getting a chance to catch the exception.
* Apparently something is causing the program to segfault while
* With slsj we are getting a segfault. Apparently, SDL's parachute is doing something, as the program terminates rather than truely crashing, but truely crashes when run in wizard mode. * It looks like SDL is not wring a parachute deployment notice to stderr.txt, but I'm pretty sure I've seen such a notice in stderr.txt in other cases.

* With -DW2 exceptions there is a unusual dialog box. This appears to be raised by MSVC++'s runtime library. (More likely it is actually the C runtime library). This unusual dialog box occurs in wizard mode as well as normal mode.

What a mess.

I'll be vacationing the next two weeks so I'll likely not be much help in fixing this problem.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]