[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
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");
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.
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/01
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Ronald Lamprecht, 2006/07/01
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows,
Tacvek <=
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Ronald Lamprecht, 2006/07/16
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/16
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Ronald Lamprecht, 2006/07/22
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/22
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Ronald Lamprecht, 2006/07/23
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/23
- [Enigma-devel] Hints in the Manual, Andreas Lochmann, 2006/07/23
- Re: [Enigma-devel] Hints in the Manual, Daniel Heck, 2006/07/28
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/24
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/26