Hi,
Tacvek wrote:
It would also explain the consistancy. The quickest way to tell is to
use --disable-nls.
Btw. Could somebody check in the fixes for --disable-nls? In one file
the output of _() is assigned to a char* when a "const char*" is what
is needed. The adding the const keyword in two places should work, I
know const_cast<char*> works but it is a c++ string, which is not
supposed to be mutable. In othe other place, somebody accidentally
used gettext() trather than _(). Both are trivial fixes.
I will check them lateron and submit the fixes with my next commit.
I tested that. Besides a few small tweaks that are needed to make it
compile
using with that, it worked.
The resulting exe also crashed.
So my next guess is an uncaught C++ exception.
A few weeks ago I managed to compile Enigma using the Visual Studio
Express. I have not checked in all the changes that were necessary,
but I can try to reproduce this error to see if it is actually a
mingw bug. I will be back in Germany on Saturday, so maybe I can
take a look at it during the weekend.
This crosscheck would be helpfull.
Meanwhile I succeeded in running Enigma on Windows under the control of
gdb (still just with the commandline interface).
Well, I found out that the functions that use lua_tostring will
normally crash if they emit an error.
Hmm... this seems to be limited to the callback. The other functions
seems to act fine in the main body.
Its starting to look like the callback and the main body bugs are quite
different.
After all, the unoptimised exe will not crash from getkind(nil) in the
body, but will
crash with that in the callback.
I had a look in gdb on the "enigma.GetKind(nil)" case - it just causes a
segmentation fault at the same line 166 in lobject.c.
In both cases immediatly before a luaM_realloc_ occured on L. That may
be the common internal reason.
If someone likes to view the step protocol of the "enigma.GetKind(nil)"
case please send me a personal mail.
- Ronald
_______________________________________________
Enigma-devel mailing list
Enigma-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/enigma-devel
