Jump to content
  • Advertisement
Sign in to follow this  

SWIG luaopen crash

This topic is 2602 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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"

Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites
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 :>

Share this post

Link to post
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.

Share this post

Link to post
Share on other sites
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).

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/

Share this post

Link to post
Share on other sites
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!

Share this post

Link to post
Share on other sites
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.

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;

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!

Share this post

Link to post
Share on other sites
[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,"]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]

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!