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

[Tacvek]

----- 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:
> > Hi,
> >
> > 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.