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

[Bruce Simpson]

Hi Ben,

This is a good catch. Thanks.

Ben Greear wrote:
> ...It's not deletion of the refptr or what it points to that is the 
> problem..it's deletion of the Node that holds the refptr.

This sounds very, very similar to the problems I found in Spt with the 
use of ref_ptr:
    
http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/libproto/spt.hh.diff?r1=1.19;r2=1.20

...that might be a good starting point for the root fix. One issue with 
ref_ptr is that merely holding one bumps the reference count. Boost has 
a weak_ptr which allows the magic of a shared_ptr to be preserved even 
when 'just passing through'.

>
> Moving to a linked list storage or something like that for nodes would 
> probably fix the problem, but considering non-const access
> to elements, it may not be worth the effort.

Agree. Considering that Selector is fast-path stuff anyway, the 
additional bookkeeping involved is probably not worth the effort.

>
> If we are worried about memory usage, should fix the lex parsing 
> code...it leaks memory all over the place
> according to valgrind.  But, I couldn't see any easy way to fix that....

If you could raise a ticket on Trac for this also, with the valgrind 
log, that would be great.

I can't promise that I could get around to fixing it any time soon, 
though. I've been up to my eyeballs in Thrift and libxipc, and have 'hit 
the wall' in more ways than one.

The Router Manager is a large and complex beast. In corporate, it's 
largely been replaced with something else. Some degree of complexity 
also exists there due to the existence of textual XRLs.

cheers,
BMS