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

[Ben Greear]

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 <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com