stepSimulation Seg Fault

[Mako_energy02]

As the title suggests, I am getting segmentation faults when I call stepSimulation in my program. I'm using Code::Blocks, compiling as debug. We have both windows and linux versions of the program, and it only seg faults in the windows version. The linux version runs fine. I started out with all the code to add objects to the world and went through all the lines and remarked them out one by one to see of any of those were passing corrupt data, however with all of them remarked out the seg faults persist. In debug, I watched all the data get passed as arguments into the stepSimulation function and they were all good, so I know the arguments are fine as well. I haven't stepped into the stepSimulation function yet as I didn't compile it as debug, so that is currently next on my todo list.

The specific versions of the OS's we are running on is Ubuntu 9.10 (again, runs fine here), Windows XP w/ SP3(32-bit), and Windows Vista w/ SP1 (64-bit).

What I want to know is if anyone that knows the internals of that function could tell me if there is something in the stepSimulation function that is different from platform to platform that would explain this behavior. Or perhaps any ideas as to a fix.

[Mako_energy02]

Update:

We are statically linking bullet to our engine with one large static library instead of the 5 smaller libraries as what seems to be the suggested way to go about it. At first we got one linking error that said there was a multiple definition of powf() in btRigidBody.o. We managed to get that fixed with a global define of HAVE_POWF. Compiled with the debug lib and I still couldn't step into the bullet code.

So next I tried following all the exact directions that are provided for compiling fresh bullet libs, or the "5 smaller libraries" as I stated earlier. Got that working but they did more of the same. There is one difference however, in both the newer version of the massive library, and the new set of smaller libraries the program is crashing sooner then before. Before they got to the stepSimulation function, but now it'll initialize bullet, create two rigid bodies, add the first, and crash when adding the second(only have 2 rigid bodies in the code so far). My first though is I messed something up with that object, so I comment them out and then it gets one line further when I set the gravity and crashes there. Commented that out too and the next function is the stepSimulation function and it crashes there as well.

I have compiled the demos, they work. We have gone over our code several times, we can't spot any mistakes, and even debugged the hell out of it to watch the variables that are being passed around to make sure they aren't getting corrupted...they aren't.

I'd be tempted to think that this is a compiler issue (compiling using MinGW), but I've seen several others on these forums using MinGW and not having the same issues I am having. I have no idea what is going on and any direction would be appreciated. I realize this may not be a bullet issue exactly, but it is suspicious that we are doing a lot in our program at the moment with a few other libraries(SDL, Ogre 3D) and the bullet code is the only thing causing crashes, but only in windows.

[Mako_energy02]

I'm not fond of triple posting and I apologize if I'm breaking any rules here. Did some more testing and it turns out the demo's that work fine were actually compiled using MSVC 2008. So at this point I'm fairly convinced something in the bullet code isn't agreeing with MinGW, or vice versa. Also looking at the forums more closely there seems to be some history of bullet not getting along with MinGW.

Why isn't MinGW more supported by Bullet? Also, any suggestions from someone that has bullet working with MinGW would be greatly appreciated.

[AlexL]

I can't really comment if it's possible to compile bullet using MinGW (but I think so, according to some posts and Erwin lately submitted a patch to make it compile but stated bullet is not "officially" tested with MinGW).
Maybe your problem is caused by different libcrt / libstdc++ versions (MSVC vs. MinGW) and passing objects through the DLL barrier? But only a guess.

[Mako_energy02]

I should probably be more clear where exactly the issue is. We have it compiling fine, it'll even link just fine. It's during run time that we have any issues at all. And it's not just StepSimulation() thats causing it like I originally thought. Without getting verbose and showing all the code: we initialize bullet, create 2 rigid bodies, then add them to the world, set the gravity, and start the main loop(with stepsimulation() in it).

With our older lib(by older I mean we compiled it 3 months ago) it would only crash at stepsimulation(). Now we've made new libs and with these it'll crash at any bullet function after adding the first object. Just a reminder, but the rigid bodies aren't the issue as commenting them out, just making it initialize and then go to stepsimulation() will cause it to seg fault/crash.

All the libraries we're using have been compiled using the same compiler(the libs and the program). We're currently looking into switching to MSVC for the windows side of the project...but it's a pain.

Thank you for the response though, good to know I'm not alone(even if I am alone in having this issue).

[Sqeaky]

AlexL

Maybe your problem is caused by different libcrt / libstdc++ versions (MSVC vs. MinGW) and passing objects through the DLL barrier? But only a guess.

What do you mean by DLL Barrier?

[Mako_energy02]

This problem is ongoing, and I'm not really making much in the way of progress. One issue after another with no end in sight with attempting to change the project to work seamlessly with MSVC. At this point, I'd like to know if I can get MinGW and Bullet to work together at all. Just some confirmation from someone that knows.

If this isn't possible at all or just no one responds...this may just be a deal breaker for me using Bullet in my project.

Edit: Slightly more research shows this issue isn't new. http://www.bulletphysics.org/Bullet/php ... f=9&t=4514