Hi all, I've got a strange issue today (well, I suppose most issues are strange before we become familiar with them . 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"
SWIG luaopen crash
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.
If you get to find the line that is failing, post the entire procedure so we can see what's going on.
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 :>
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 :>
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.
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/
[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/
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!
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!
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]
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]
[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]
[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]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement