Closed jdumas closed 6 months ago
If you allocate a refcounted object on the stack and take a reference, you need to call object.SetEmbedded()
to signal the reference counting system that you're responsible for cleaning it up.
So:
BoxShapeSettings floor_shape_settings(Vec3(100.0f, 1.0f, 100.0f));
should be
BoxShapeSettings floor_shape_settings(Vec3(100.0f, 1.0f, 100.0f));
floor_shape_settings.SetEmbedded();
in this case. In the original HelloWorld example, nothing takes a ref to the BoxShapeSettings object so it's fine in that case to skip the call.
I see, thanks for the tip! It might be worth mentioning this use-case in the HelloWorld example maybe? I feel it's an easy mistake to make since the HelloWorld example make it look like it's ok to have those objects be stack-allocated without doing anything special.
Closing this issue since you've answer the initial question.
Done.
Consider the following modified
HelloWorld.cpp
example:Running the program in Debug mode exits with the following:
I think the issue comes from the parent
DecoratedShapeSettings
object that takes a raw pointer as input: https://github.com/jrouwe/JoltPhysics/blob/4deaf12b3c12d5890d0cc0d55234fef54d63436b/Jolt/Physics/Collision/Shape/DecoratedShape.h#L20-L24The function signature suggests that it is safe to pass a raw pointer to a stack-allocated
BoxShapeSettings
for example. But because the object becomes refcounted, destroying theRotatedTranslatedShapeSettings
will attempt to destroy the previously stack-allocatedBoxShapeSettings
.I don't know if this design is intentional. I would argue that the
DecoratedShapeSettings
should take as argument aRefConst<>
to prevent this kind of situation. At the very least theHelloWorld.cpp
example suggests that it's ok to stack-allocate shape setting but this can lead to this kind of tricky situation. Let me know what are your thoughts on this. Thanks!