[Top][All Lists]
[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
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/01
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Ronald Lamprecht, 2006/07/01
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/01
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Ronald Lamprecht, 2006/07/16
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/16
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Ronald Lamprecht, 2006/07/22
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/22
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows,
Ronald Lamprecht <=
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/23
- [Enigma-devel] Hints in the Manual, Andreas Lochmann, 2006/07/23
- Re: [Enigma-devel] Hints in the Manual, Daniel Heck, 2006/07/28
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/24
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/26
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/26
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Ronald Lamprecht, 2006/07/26
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/27
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Ronald Lamprecht, 2006/07/27
- Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows, Tacvek, 2006/07/29