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

[Ronald Lamprecht]

Hi,

Tacvek wrote:
> It is probably not a great idea to be using longjmp anyway. Based on my 
> reading of the C standard
> There is a decent chane that a compiler will not clean up properly under 
> certain circumstances. This can be
> even worse under C++ because the compiler has to take care of a lot more 
> housekeeping. If the compiler managed to
> botch this in some way or other a segfault is exactly what I would expect.

I made 2 further experiments:

Enigma 0.92 compiled with mingw --enableSJLJ:
No problem with "enigma.GetKind(nil)" on load of level!
But problems within callback, and "enigma.GetAttrib(sender,
"notexisting")" in both cases.

Enigma 0.92 as Daniel compiled it (probably without --enableSJLJ !?):
No problems with any of these crashes!
@Daniel: which compiler configuration did you use?

> > One experiment would be to compile Lua as C++ - this would guarantee the
> > same exception mechanism being used in Enigma and Lua. (Some Enigma
> > sources would need minor adaptation. No idea about tolua++' exception 
> > dependency). The effects on SJLJ and DW2 would be interesting.
>
> Does tolua++ touch exceptions or lua errors in any way? I don't think it 
> uses pcall (protected call) so the lua errors would propgate back up to 
> Enigma.
> I'm not sure that many changes would be needed to enigma's source. Lua 
> would not be expecting us to catch these exceptions.
> It would catch them internally and indicate the error in the same way as 
> normal. So the key would be not accidentally catching lua's exceptions
> If needed we can catch them explicitly and rethrow them so that they get 
> back to Lua.

Tacvek will you patch Enigma for this experiment? It is worth while!

> > On the other hand a Visual Studio Express compilation should use
> > Microsoft SEH. Another chance to bypass tan expection handling problem.
>
> I also have a full install of VS 2005, but I do prefer being able to 
> cross compile, because everything runs so much
> nicer. Bash scripting is far more powerful than CMD.exe scripting.

The maintainance of two different scipts is always a burden.


As the problem seems to be located in mingw's error handling running 
into trouble with intermixed Lua-C errors and Enigma's C++ errors I 
started wondering why we throw luaL_error() at all! Why not throwing a 
C++ exception in lua.cc in case of an error? Let us unwind directly over 
all the Lua code back to our own code.

And it runs seamlessly!

We would just need to define a new error "XLua" that we can throw during 
 level loading as well as in runtime. This error can be caught and 
rethrown as the specific error.

@Daniel: are there any reasons to use luaL_error() in favour of C++ 
expections? I am not aware of any cases were we will try to reuse a 
faulty Lua state.

Of cause this is a workaround that depends on avoiding the mixture of 
Lua-C errors with C++ errors. It may not be safe on errors thrown within 
Lua code. Thus the experiment with Lua using C++ is very interesting and 
with a good chance of success!


- Ronald