[Xorp-hackers] valgrind: selector.cc: Reading free'd memory

[Bruce Simpson]

Ben Greear wrote:
>
> The problem is that a method called by an object can cause that object
> to be deleted, and when that method continues, it is accessing deleted
> memory.

SelectorList::Node::run_hooks(), right? That one *is* nasty... (re comment)

WinDispatcher doesn't have this problem; there, the callbacks are held 
in separate maps, and  the ref_ptr for the callback protects the 
callback itself; where multiple dispatches are taking place within a 
for-block, the iterators involved are protected also.

SelectorList::Node does not have such protection -- it's entirely 
possible that the callback will go off and try to remove an event, but 
as soon as it does, it can invalidate the SelectorList::Node. The 
protection in run_hooks() seems insufficient...

Are there specific places where this is triggered? The comment would 
seem to indicate it's only an issue if more than one callback runs on 
the same FD, which is certainly possible even if they're *not* for the 
same IoEventType.