[cc'd to flightgear-devel, as this is clearly an architectural issue and not a bug report.]
The basic issue as I understand it is that apparently SGPropertyNode::removeChild() has been (incorrectly, AFAICT) modified to ignore nodes that have a reference count greater than one, which interacts badly with the case where a Nasal script has created a Node object (which includes a refcounted pointer, obviously) that has yet to be garbage-collected. Melchior FRANZ wrote: > removeChild() doesn't remove nodes with refcount != 1, nor their children > (independent of their counter). After destroying the SGPropertyNode_ptr > you return to count == 1 (i.e. only referenced by parent). Same state > as before calling removeChild(). Nothing will be deleted by that. Why not? This sounds like a bug to me. What is wrong with removing a node that someone else is holding a reference to? When they free their reference, then it gets deleted. > No. removeChild/ren() is correct. Just don't take guarded pointers > from nodes that you want to remove. That's not possible in Nasal. You create the refcount in getNode(), and have no way to know whether the script intends to delete it or not. Let me put it more forcefully: if proper reference counting semantics are going to be removed from the property system, then the current Nasal props.Node interface WILL NOT WORK, and all code will have to be ported to the stateless getprop()/setprop() interface instead. Seriously: what is the "bug" being fixed by the ignoring the refcount thing? The whole idea behind reference counting is to *remove* the requirement for this kind of logic. Andy _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
