Should btBroadphaseInterface destructor remove itself from btCollisionObject broadphase proxies?

[radarsat1]

I don't know Bullet very well so apologies if this doesn't make sense. But, I just fixed a crash-on-exit bug in a program that uses Bullet. The problem turned out to be that a object managing Bullet was using std::shared_ptrs to keep btBroadphaseInterface and btCollisionWorld pointers, among other things. I noticed that the problem was fixed if I explicitly destroyed the btCollisionWorld object instead of letting the shared_ptrs take care of it.

It turns out that during the btCollisionWorld destructor, it makes some dereferences of a broadphase proxy that references the btBroadphaseInterface. However, due to the order of the variables declared in the manager class, the btBroadphaseInterface was getting destroyed first, leading to a segfault during the btCollisionWorld destructor.

I was wondering if an acceptable solution would be for btBroadphaseInterface to remove any proxies that point to it during its destructor? That way there would be no order dependency between their destructors. However, maybe it's impossible, or even wasteful, since it would require a sweep through all broadphase objects just before they are destroyed. Otherwise, any ideas on how such a segfault could be warned against or avoided?

[erwincoumans]

Yes, it is recommended to explicitly destroy objects in the reverse order of construction, don't use smart pointers etc. Memory in Bullet is managed explicitly in the right order, not in random arbitrary order.
I envy C-API's that make such smart pointer mess-up harder :)

[radarsat1]

Ok!