Sign in to follow this  

SWIG luaopen crash

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: [url=""]http://forums.codebl...hp?topic=3286.0[/url] which might be relevant.
and this one:

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
Specifically, I'm deleting what [i]was[/i] head. The contents of a messagenode are all pointers, so I'm just copying the contents into toreturn and then returning it. This functionality is confirmed by the fact that it works in all cases I've seen... except for this one strange one The arguments to this strange one are identical except there is one extra one at the end (an int packed in... note that all arguments -- arg1 through arg5 -- are stored in message objects as void*). Of course, it is very possible I'm missing something, in which case the revelation will likely cause my to facedesk :P

As an experiment (and potential replacement) I'm in the process of commenting out and replacing my custom queue with an implementation based on STL deque. If it works then we'll know pretty certainly that there is some problem somewhere with my custom queue... though I don't see how there can be. Still not sure why the thing works properly in XP compatibility mode but I suppose some unknowns are meant to remain as such.

Share this post

Link to post
Share on other sites
I completed the conversion from my custom queue to deque and the problem has not been resolved -- it acts exactly the same... I have done a little testing and the value that gets lost (specifically the filename in the below)

DispatchMessage(mids.CREATE_SHADE_OBJECT, ".\\dat\\002_GENERICSHADE.txt", 0.0, 0.0, 0.75, 501)

is successfully pushed onto the queue, but is somehow lost by the time I remove it from the queue (the value is an empty string by that point). This problem does not affect any other calls, at least with the sandbox script set up the way it is. Note that I don't touch that entry until it is popped off the queue.

[edit] If I commment out all the CREATE_SCENERY_OBJECT message dispatches the above one runs properly... but if even one is left it crashes... The only modification of the queue is pushing and popping of message objects, which are defined as follows

class Message
bool CompareAgainst(Message target);

int type;
void *arg1, *arg2, *arg3, *arg4, *arg5; // Argument Storage

arg1 is where the filename gets stored. I know void pointers aren't really the best option, but they were the only convenient thing I could come up with when designing my messaging system (which needs to support arguments of more or less arbitrary type -- hence the handlers for messages know what types they are based on the type variable and cast them back to something usable).

[edit] It also runs perfectly in windows 7 compatibility mode... that just doesn't make any sense.

Share this post

Link to post
Share on other sites
In massively boring style :lol: it turned out to be an eccentricity of lua_tostring where, basically, the string it returns can be de-initialized at a fairly unpredictable time, apparantly. Buffering the string solved the problem.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this