The viewer uses a delayed free mechanism where Items that hit a refcount of zero are added to a list that is then actually deleted on the next call to Reset or UpdateFromModel. This breaks down when the viewer is destructed - the weak pointer to the viewer fails to lock (the viewer's refcount has reached zero, it is being destructed), and so the objects never get sent back to the viewer for deletion. In this scenario, delete the objects directly to prevent memory leaks when the viewer is repeatedly opened and closed.
There's a larger question about why the deleter is implemented this way - it appears that when the delete list is processed the only thing done other than delete is PrepForDeletion, which resets the user data pointers on the kinbody item. There is no comment explaining why this is necessary / this cannot be done in the ordinary-course destructor.
The viewer uses a delayed free mechanism where
Item
s that hit a refcount of zero are added to a list that is then actually deleted on the next call to Reset or UpdateFromModel. This breaks down when the viewer is destructed - the weak pointer to the viewer fails to lock (the viewer's refcount has reached zero, it is being destructed), and so the objects never get sent back to the viewer for deletion. In this scenario, delete the objects directly to prevent memory leaks when the viewer is repeatedly opened and closed.There's a larger question about why the deleter is implemented this way - it appears that when the delete list is processed the only thing done other than
delete
isPrepForDeletion
, which resets the user data pointers on the kinbody item. There is no comment explaining why this is necessary / this cannot be done in the ordinary-course destructor.