On 10/01/2009 04:11 AM, Bruce Simpson wrote: > 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.
As soon as the memory is free'd due to resize, all bets are off and the loop might think it should continue even when it shouldn't have because something else has acquired and written to the memory before the loop completes. We have to ensure that the Node memory can never be deleted while that method is running. My work-around solves this for any sane amount of file-descriptors (up to 1024). My patch is better than what previously existed, but some day we could revisit the whole logic in that area perhaps. Thanks, Ben -- Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
