On 18 Sep 2012, at 22:33, Thomas Geymayer wrote:
While searching for the reason of crashing FlightGear if trying to
remove the nodes of the previously selected airport in the new Select
Airport Dialog I stumbled upon a problem with the behavior of
SGPropertyNode::removeChild. If you remove a child then fireChildRemoved
is triggered and every listener is getting informed. The problem is that
it is only called for the node being removed but for non of it's child
nodes. So if you listen upon a specific node being removed and instead a
parent node is being removed you will never get notified and have a
pointer to an invalid part of your memory which can cause a crash :)
I've pushed a commit witch recursively triggers childRemoved for all
nodes controlling the canvas. Any objections on moving this behavior
directly into simgear?
I don't think firing this recursively is a good idea - it means remove nodes
near the root of the tree becomes very high cost. Isn't it better to just
document the behaviour very clearly somewhere, and modify the listeners that
care about it (which are very few). In other words, the fix is to have the
listener watch all the parents (ancestors) that might possibly be removed.
I appreciate that's a little ugly, but it keeps the balance of work the right
way around - removing nodes stays generally cheap and simple, and listeners
that care about deeply-nested children being remvoed have to watch for that
explicitly.
James
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
