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

[Ben Greear]

On 09/30/2009 08:51 AM, Bruce Simpson wrote:
> 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

The problem I found has nothing at all to do with pointers, weak or otherwise.

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.

>> 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.

It's a one-time action, so the leaked memory isn't too big of
a deal to me.

I have some more regression tests to run and I'm finding bugs everywhere
I look (in xorp and my own code too for that matter).  My plan is to run
under valgrind some more, fix easy valgrind bugs and all possible crashes.

Then, run under oprofile and try to optimize things.  OLSR burns 100% CPU
during re-configure, and xorpsh seems fairly expensive to launch as well.

> 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.

That reminds me:  What is the plan when 'corporate' releases their
code to customers?  Since it's GPL, we will then have access to the source.
Do you plan to merge their tree with the public SVN tree at that point?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com