pointer issues....

[buhatkj]

Hey all,
I am trying to make a .dll that links with Irrlicht. My .dll compiles, but when i make a test application, if i use any of my own objects, which reference irrlight scene nodes they bomb out during runtime, and throw this error that i hit a "user breakpoint", and it opens up dbgheap.c in VC++. now this code it open up for me to debug seems to handle some functions for windows that allow it to allocate memory and manage pointers in the heap. the comments in that file say that a common reason that this condition is reached, is because of a "non-local pointer", which is says can happen if a .dll has the "CRT" linked in. Irrlicht does indeed link in something called "crtlib.h" or something. Basically I'm stumped... If i just export the irrlicht primitives from my dll, and use them from my app, they work, but if my dll uses them, it bombs. I even tried rebuilding irrlicht as a static lib, and linking that in to my dll that way, now i just get a different pointer-related error! does Irrlicht do some sort of wierd memory management, or is what I want to do just not possible? It's wierd, because I do a similar thing(use a dll FROM a dll...) as you will see with audiere, and it seems to work great....
...HELP!!
my code is at: http://buhatkj.dyndns.org:4242/downloads/fnord.zip

THANKS!!
-Ted

[buhatkj]

after carefully researching the error messages and restructuring my dll, I finally figured out on my own what the issue was.
Ultimately, the error i was getting was a bad call to rtlValidateHeap(0x,0x); at runtime. I knew this had to do with the CRT library being used in Irrlicht, so after messing with it for quite a while, I figured out that if I explicitly told VC++ to not re-link the CRT lib, then it works. The way I do this is to edit the "command line" option in the project build options in both my DLL and the app using it and add "/MD" to it, which tells the linker/compiler not to re-link the CRT, because if it does Irrlicht freaks out and throws that invalid pointer error.
I think the reason this is an issue, is because the data I am using is technically in the memory space of the Irrlicht DLL, and is dynamically being referenced ACROSS my DLL and ultimately in the user-space of my test application.
It really sucks to have worked for like a week on such a fundamentally stupid bug, but I guess that is how we learn
I wish i could have gotten the heads up on what this was earlier from somebody here, but it was a very complex and specific type problem, so I dont blame anybody. So anyways, if any of you guys run into this, that's what to do!
-Ted

[Serapth]

Well, your mostly right. Im not sure which Visual Studios version you are running, however in all versions of them from 6 up that I can recall, you dont actually have to manually edit the compiler switches. The /MD switch in 6 is actually set by going to Project Settings -> C++, select Code Generation for Category, then "Use runtime library". This determines which c-runtime the program is linked to.

The problem you ran into, is most likely you are using the precompiled version of Irrlicht, which I think is compiled either multi threaded DLL(/MD), or Multi threaded DLL debug(/MDd).

Your other option would be to add the Irrlicht build to your solution, so that everything consistantly links the same way. You will find going forward however, that the runtime version of 3rd party libs needs to be the same as your app, or vice versa. You just discovered the hard way! I would highly recommend you add Irrlicht as a subproject within your solution, and as a dependancy for your app. It will save you a great deal of hurt going forward, and will make debugging and profiling a lot easier in the future.

Cheers,
Mike



Oh and hi all, im new here. Just evaluating Irrlicht sofar, but im very impressed. Downloaded it and had 3d objects zooming around screen in less then 20 minutes, very impressive.

[buhatkj]

welp, you are 100% right man, i went where you told me in my Visual c++ 2003 project build settings and there it was, I set it to "multi threaded DLL(/MD)" in both of em' and removed the thing I had added to the "command line" bit, and recompiled everything, and it worked great. I dunno about adding irrlicht as a dependency, I don't actually build both my dll and the test app in the same solution. I wanted them to be as seperate as possible, to simulate the experience of the modder making their own thing from scratch. I am going for maximum usability with this
Once again, thanks for the great tip/advice
-Ted