Hey !
I’ve had a severe issue on my Windows builds concerning CollisionNodes and CollisionSolids.
After a lot of investigation, I believe I have a little idea of what’s happening, though I still have no idea why or how it happens.
What’s the problem ?
Calling the method CollisionNode::add_solid systematically concludes with a crash (assertion failed, invalid type handle, and the type handle displayed is obviously picked up from some uninitialized memory - changes at each run).
Now my last experience was to reimplement add_solid on my side of the code, rather than in the Panda library.
It consisted of moving the CollisionNode::_solids variable from private to public in the header, and write my own method that would do exactly what CollisionNode::add_solid do:
int CollisionNodeAddSolid(CollisionNode* node, CollisionSolid* solid)
{
node->_solids.push_back(solid);
node->mark_internal_bounds_stale();
return (node->_solids.size() - 1);
}Now if you do something like this:
void CollisionSolidTest()
{
PT(CollisionNode) node = new CollisionNode();
PT(CollisionRay) ray = new CollisionRay();
CollisionNodeAddSolid(ray); // Will not crash
node->add_solid(ray); // Will crash
}The two procedures do exactly the same thing, but for some reason, only the one from my own code doesn’t crash.
As it happens, CollisionNode is instantiated in my code as well. Which means that, in order to build this CollisionNode, the program used the understanding of what CollisionNode meant for my own compilation (not the compilation that generated the Panda3D libraries).
My bet is that if it was instantiated from the Panda3D side, my procedure would fail, while Panda3D’s procedure would succeed. And since I was able to fix the issue by replacing the pvector with a vector, I believe the misunderstanding might happens in pallocators. But it’s pretty much impossible to infer so…
Of course if such an issue happened at one place, it might’ve happened on some other stuff as well (I’m getting ready for the worst).
The question is why do my program interpret Panda3D’s headers differently than makepanda ?
It’s not just a problem of different building environments: I was able to reproduce the issue both with the pre-compiled packages of Panda3D 1.9.0 (last one I tried with was the 32bit build 198) and with a Panda3D 1.9.0 that I compiled myself with this same environment.
And another quick question.
Is there a way to obtain the list of all the defines used during the compilation of Panda3D ? Maybe if I set all these defines as well in my project, this issue will stop occurring.
EDIT: I put a little experiment in place, I made a build of Panda with a factory in CollisionNode: and just as I thought, the CollisionNodes returned by the factory didn’t crash when I called add_solid.
Yet the header files are taken from the proper build directory. The only possible thing left in my mind is some defines interpreted differently.
EDIT-2: Actually, this isn’t linked to Windows. I’ve been able to reproduce this issue with every build I’ve made of Panda3D on Ubuntu, Fedora and Windows in 32bit. All the 64bit builds were perfectly fine however.