[Top][All Lists]

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

Re: [Enigma-devel] crashes on linux gcc exception handling

From: Tacvek
Subject: Re: [Enigma-devel] crashes on linux gcc exception handling
Date: Sun, 24 Sep 2006 20:36:16 -0400

----- Original Message ----- From: "Daniel Heck" <address@hidden>
To: "Ronald Lamprecht" <address@hidden>
Cc: "enigma-devel" <address@hidden>
Sent: Sunday, September 24, 2006 1:55 PM
Subject: Re: [Enigma-devel] crashes on linux gcc exception handling

Ronald Lamprecht wrote:

Daniel Heck wrote:
2. switch Lua to C++ for Linux and other OS, too

As approach 1. means a lot of work and would force a rewrite of all
tolua based code I would prefer the second solution.

Is anyone aware of other solutions? Does anyone object solution 2?

I think this would be a reasonable solution for the moment, although I'm
not sure that this is safe from Lua's perspective.  For example, I'm not
sure that this couldn't lead to memory leaks in the Lua interpreter, or
leave the Lua interpreter in some inconstistent state.

As we release the Lua interpreter as part of the level abortion we
should not run into trouble. You can test the fix by configuring the
current revision with option "--enable-cxxlua".

Ah, I see.  I also hadn't noticed that Lua is configured to use C++
exception handling instead of the usual longjmp when it is compiled as C++.

That was all part of the Windows workaround. I very intentionally made sure that --enable-cxxlua worked fine under linux. The real reason was because the native c++ compiler was faster, so it enabled quicker turnaround time for testing. (Ok I messed up that configure flag the first time, but the second time I got it right.)

It doesn't solve another problem: Lua scripts still don't have a chance
to handle errors raised in the Enigma engine.  A better (long-term)
solution might therefore be to map C++ exceptions to "lua_error" or
luaL_error calls.   I don't think that this is an urgent issue at the
moment, and I'm not sure that tolua would support this, but it's
certainly something to think about.

Well, we currently do pass some errors back to lua via lua_error. Tolua++ does not seem to mind. Lua then uses either longjmp or c++ exceptions to effectively unwind the stack. It passes the message back to enigma, which promptly converts it to a c++ exception and tosses it. The catch statement finally aborts the level and prints the error message.

So currently there are three types of errors:
1. Lua code internally raises an error. (Dispatch internally with longjmp or c++ exceptions. If not caught by internally with a pcall, is handed to Enigma which converts it to an exception and throws it.)
2. C code raises a lua_error. This is handled exactly like the above.
3. Enigma raises a C++ excepetion.

For all of those the end destination is a c++ error handler that aborts the level and prints the message. Except: Lua code can trap types 1 & 2 using pcall. [I'm not aware of any levels that do, but it is certainly possible].

Daniel is proposing that at some point we convert some of the type 3's into type 2's if appropriate. Obviously if the problem could not possibly be handled by a lua script there would be no good reason to convert a type 3 to a type 2.

Note that this bug is affecting type 3 errors only. I suspect it is potentially possible to use only type 2's. That would solve the problem on Linux
and would allow lua scripts to trap errors.

The only downside is that a lua program would trap an error that it is incapable of handing. If it fails to rethrow the error in such a case it would be bad. It could either crash, or it could result in the usefull error message being replaced with a less useful one created by lua's internals.

Note that that change would have no inpact on the Windows bug.

reply via email to

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