The CBullet constructor does store this though (in m_body), so it could feasibly be used to later delete it. Not a design I would use...

that's really beyond hacky :P .. but I expect nothing less from a juventus fan :D

I would say Columbo's is the right diagnosis... I bet there is a compiler warning saying something in the lines of "delete called on undefined object, no destructor called".

You're trying to retrieve the CBullet object pointer from the fixture's userdata but you're storing it as the body's userdata - I think this may be the problem?

yeah, you're right, thanks very much and now my program throw a runtime error just like what i hope

i little tweak and it should be no problem anymore

but i still don't understand why the other function(except destruction) still can be called even if i'm retrieve the wrong userdata

Are they non-virtual? The correct function will be called then (the this pointer would be junk though if you call it on the wrong object type). Virtual functions (I'm guessing the destructor is virtual due to overriding a virtual destructor in a base class) need a valid this pointer.

Presumably the userdata you tried to delete was null before the fix... which would explain why no destructor was called (deleting a null pointer is valid, no destructor is called).

Since you were logging stuff when you called the destructor you should consider logging allocations (log the type and address in the constructor) and deallocations (same deal in the destructor) to help debugging similar problems later on.

Since you were logging stuff when you called the destructor you should consider logging allocations (log the type and address in the constructor) and deallocations (same deal in the destructor) to help debugging similar problems later on.

Thanks for the explanation although i don't know how to do the allocations and deallocations logging things because usually i'm using callstack to track null pointer :D