SWIG luaopen crash

Started by
10 comments, last by medevilenemy 12 years, 10 months ago
Hi all, I've got a strange issue today (well, I suppose most issues are strange before we become familiar with them :P. Anyway, I am adding a second SWIG module to my current project, as I want to separate things with different purposes. This second module is called general, and right now all it does is expose a pair of extern char variables in a header of mine. Everything seems to work fine, but when I try to run once I've called luaopen_general, the program runs for a moment then hangs/crashes. I have even cleared out the module so that it doesn't actually expose anything and I get the same problem. Curiously, running the program in XP compatibility mode seems to alleviate the problem. Relevant code below:

%module general

%{
#include "ImportantGlobal.h"
%}

%include "ImportantGlobal.h"
There was a saying we had in college: Those who walk into the engineering building are never quite the same when they walk out.
Advertisement
Mmh. How does the application crash? Does it throw an exception?Have you debuged a little to see exactly which line of your code is failing? Maybe it is giving you a return value with the error that you can check?

If you get to find the line that is failing, post the entire procedure so we can see what's going on.
[size="2"]I like the Walrus best.
All I know is the addition of the call to luaopen_general causes a crash, and the lua runtime doesn't report any error. Does luaopen_* seems to return 1 regardless of situation.

Curiously, if I switch to a newer version of the openal dll (I use openal for audio, and I recently switched to an older version of the dll as a test for a friend), everything works fine again :>
There was a saying we had in college: Those who walk into the engineering building are never quite the same when they walk out.
cool then :)
[size="2"]I like the Walrus best.
Sorry, deleted my last message a little too slowly... it seemed to be working, but now its not working again. Running in XP compatibility mode still "fixes" it. This is very odd.
There was a saying we had in college: Those who walk into the engineering building are never quite the same when they walk out.
Update: I tried commenting out a single line in one of my lua scripts which tells my code to load an ogg vorbis file.... and everything else works fine... Put that line back in and comment out a line that causes another script to be run, and everything works fine... Remove the luaopen_general invocation and leave everything else (including audio) running -- and everything works fine... I may have to resort to using GDB (I do wish I had a better debugger compatible with mingw generated executables).

[edit]
Here is the output from gdb: Note that there are no popup errors or anything like that about missing dlls, nor am I multithreading my code, nor have I any idea how to figure out what the dlls starting at those addresses are supposed to be.

------------------------------------------------------------------------------------
[New thread 1736.0x12c4]
Error: dll starting at 0x77050000 not found.
Error: dll starting at 0x75ce0000 not found.
Error: dll starting at 0x77050000 not found.
Error: dll starting at 0x77170000 not found.
Error: dll starting at 0x320000 not found.
[New thread 1736.0x1028]
[New thread 1736.0x3f4]
Error: dll starting at 0x8030000 not found.
[New thread 1736.0x1338]
[New thread 1736.0x1100]
[New thread 1736.0x12f0]
[New thread 1736.0x360]
[New thread 1736.0x6cc]
[New thread 1736.0x1314]
[New thread 1736.0xfe8]
[New thread 1736.0xe9c]
[New thread 1736.0x184]
[New thread 1736.0x1218]
[New thread 1736.0xb20]
[New thread 1736.0x150]
[New thread 1736.0x119c]
[New thread 1736.0xdb4]
[New thread 1736.0xdd4]
[New thread 1736.0x1198]
[New thread 1736.0x11fc]
[New thread 1736.0x380]

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Program exited with code 03.


--------------------------------------------------------------------------

[edit] I found this thread: http://forums.codebl...hp?topic=3286.0 which might be relevant.
and this one: http://www.gamedev.net/topic/549073-mingw-on-64-bit-windows/
There was a saying we had in college: Those who walk into the engineering building are never quite the same when they walk out.
I am attempting to adjust my code to get it to build in code::blocks (which is running a much newer version of MinGW) to see if the newer version resolved the problem -- at least to a point (I'm not trying to build 64 bit code, simply trying to get the ostensibly 32 bit code to play nice with 64 bit windows). Anyway, I'll report on the effectiveness of that if I can get it to work (right now, I'm having some annoying linker errors like:

undefined reference to std::ctype<char>::_M_widen_init()

Not sure how to resolve it, but I'll keep at it. If anyone has any thoughts on this or the mingw problem, I'd be quite interested to hear. Thanks!
There was a saying we had in college: Those who walk into the engineering building are never quite the same when they walk out.
Got it to build in code::blocks. Didn't solve the original problem, unfortunately.
There was a saying we had in college: Those who walk into the engineering building are never quite the same when they walk out.
After upgrading the version of MinGW in my Code::Blocks installation, The weird dll related errors in the gdb readout go away, leaving "warning: Invalid parameter passed to C runtime function" and a "This application has requested the Runtime to terminate it in an unusual way".

This is really weird, as such things tend to be... I can trace the problem to somewhere around the dequeue function in my message handler -- for a single type of message, if I comment out the call for that message type in my sandbox script, the program runs perfectly again... weird thing is all messages go through the same function and they all work properly. All I can tell is that in the function below, arg1 (a void* in this case storing a string) gets corrupted, thereby causing problems later down the line. arg1 is fine when it is placed on the queue, as far as I can tell. I don't know if I've made some strange subtle error somewhere, or if the executable the compiler generates is a little wonky as suggested in those links, or what.

[source]
Message MessageQueue::DeQueue() // Returns the Message stored at the front of the queue
{
Message toreturn;
MessageNode *currenthead;
if(head == NULL)
{
toreturn.type = EMPTY_MESSAGE; // Flag return value as empty
toreturn.arg1 = NULL;
toreturn.arg2 = NULL;
toreturn.arg3 = NULL;
toreturn.arg4 = NULL;
toreturn.arg5 = NULL;
return toreturn;
}
else
{

toreturn = head->data; // Copy the data
currenthead = head; // Copy a reference to the current head
head = currenthead->next; // Set head to point to second item

delete currenthead; // Delete old head node

return toreturn; // Done!
}
}
[/source]
There was a saying we had in college: Those who walk into the engineering building are never quite the same when they walk out.
[font="Consolas,"][source lang="cpp"[/font]]
[font="Consolas,"]toreturn = head->data; // Copy the data[/font]
[font="Consolas,"]currenthead = head; // Copy a reference to the current head[/font]
[font="Consolas,"]head = currenthead->next; // Set head to point to second item[/font]
[font="Consolas,"]delete currenthead; // Delete old head node[/font]
[font="Consolas,"]return toreturn; // Done![/font]
[font="Consolas,"][/source][/font]
[font="Consolas,"]
[/font]
[font="Consolas,"]You are equaling head's data to toreturn, then you equal currenthead to head and then you delete currenthead. By doing that you're also deleting head, thus, the data pointed by it could be getting destroyed if it wasn't dynamically allocated.[/font]
[size="2"]I like the Walrus best.

This topic is closed to new replies.

Advertisement