enigma-devel
[Top][All Lists]
Advanced

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

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


From: Ronald Lamprecht
Subject: Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows
Date: Sun, 23 Jul 2006 09:19:58 +0200
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

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.

Why should Debian not appreciate Enigma using C++ exceptions in Lua on Windows compilations?

If the changes limit to the header includes like
extern "C" {
#include "lualib.h"
#include "tolua++.h"
}
we should be able to limit the Lua C++ compilation to Windows/MinGW.

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?

luaconf.h:
/* C++ exceptions */
#define LUAI_THROW(L,c) throw(c)
#define LUAI_TRY(L,c,a) try { a } catch(...) \
        { if ((c)->status == 0) (c)->status = -1; }
#define luai_jmpbuf     int  /* dummy variable */


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.

Workarounds are never great. But it is great to have a workaround!

BTW the workaround does not change anything to the current situation. We already have 2 error mechanisms. Currently Lua-Errors are used for errors in lua scipts and faulty arguments in lua.cc. C++ exceptions are thrown within the simulation engine and wind up over the Lua part back to the catch statements in game.cc and server.cc. We would just shift the faulty arguments in lua.cc to the second error mechanism.

As the bug is located somewhere in the MinGW handling of C++ and C exceptions we have the following possible solutions:

1. Fix the GNU compiler in mingw - it would be great if someone fixes the problem itself.

2. Do no longer use the GNU compiler

3. Avoid the segmentation faults produced by gcc by switching the application to use C++ exceptions only (if this works)

4. Avoid as many situations of C/C++ exception mixtures as possible - the workaround - to reduce the likelihood of crashes.

In this situation I would prefer solution 3 if it works.

- Ronald






reply via email to

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