It's hard to be sure with just this information, but it appears that you're establishing a circular reference between the Character and Avatar instances. Most likely you don't break this circular reference anywhere, thus forcing the gc to do that for you when it detects that the character is no longer referenced anywhere else.

The way the gc breaks circular references is simply to release any handles that are held in the members, and as such setting the members to null. The destructor will be called when no more references to the object exists, i.e. after the gc has broken the circular references.

As weak links are not yet supported (and I currently have no idea when/if they will be) my suggestion is that you design your classes in such a way that you can guarantee that any circular references can be broken before all references are released. For example, you probably have some event when a character is removed from the scene, that would be a great place to call a method on the Character class to do this kind of clean up.

Sorry for coming into this late, but could this possibly be resolved (in this particular case, and maybe in others) by having the gc preferentially releasing handles that are members of objects with no destructors?

That is, in this case the gc would first release the Character::avatar handle. At this point, the Avatar would have no more references, and could be destructed safely.

Of course, this solution doesn't quite work if you have circular references between classes that each have destructors, but then that is the programmer's own fault, right?

This method of breaking circular references is used by Python and the Boehm GC, although the way each of these handle the case of circular references among objects that all have destructors is to never collect the objects . . . I think that your solution is better in this case. Or, perhaps, throw an exception and refuse to run the destructors. That sounds more complicated, though.