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

[Tacvek]

----- Original Message ----- 
From: "Ronald Lamprecht" <address@hidden>
To: "Tacvek" <address@hidden>; "Daniel Heck" <address@hidden>
Cc: <address@hidden>
Sent: Saturday, July 22, 2006 5:59 PM
Subject: Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows


> 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?


My best guess was that he was still using Debian's mingw32 (3.3.1).

I had definately not upgraded by that time. However I think something 
required me
to update since then.


> > > 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!

I can try. Unfortunately this means that we would be deviating from
a normal Lua static library, which Debian will not appreciate.

I can certainly work on this patch. Are you aware of any catch-alls that 
might be
in the unwind path of a lua exception?



> 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.

Lua would still use luaL_error()'s mechanism for internal errors, or errors 
in the lua script,
such as divide by zero, so we would need to maintain 2 error mechanisms.
That is not great. It might work, but is not great.