[Spread-users] Another way to leak (valgrind report)

Ryan Caudy rcaudy at gmail.com
Mon Aug 30 23:16:11 EDT 2004

Jonathan did apply Theo's sl_destruct patch to CVS last spring, and my
groups rewrite (not yet available from CVS) also uses sl_destruct to
prevent these sorts of leaks.

Dave, what version are you using, 3.17.2?  or CVS?

Theo, for those of us who aren't in the know, what is the arena
system?  I don't recall the patch, but it may have been before my
time.  I know that the skiplists are an important part of Spread's
scalability, and anything that improves their performance would
certainly impact the groups layer's CPU performance.


On Mon, 30 Aug 2004 22:59:14 -0400, Theo Schlossnagle <jesus at omniti.com> wrote:
> On Aug 30, 2004, at 9:32 PM, Jonathan Stanton wrote:
> > From the internal tracing of Spread when running your memory abuse
> > programs I saw the total memory used increase (as you did) but I did
> > not
> > see any leaks in the actual allocated structures. My theory is that the
> > leak is in skiplist code which does it's own memory allocation and
> > thus is
> I'll stab at it a little differently.  The skiplist code is used
> heavily in some other applications that have been valgrinded
> extensively.  I'll bet it is improper use of the skiplists in group.c.
> I'm pretty sure I contributed back most of the generic fixes to the
> skiplist code.
> The groups code is pretty complicated and most likely a skiplist isn't
> being freed or some such thing.  I could have sworn I submitted a patch
> (long ago) that makes the skiplists use the arena system.  BTW,
> substantial performance benefits can be achieved by doing this.
> Also, I am pretty sure this was all addressed on this list on Feb 21st.
>   I posted a patch and it was never committed to the repository as I
> asked for people to test it.  taj.khattra at pobox.com confirmed that the
> patch did indeed address the problem.  Feel free to commit it if you so
> desire.
> > not traced by Spread. This valgrind report also indicates the skiplist
> > code is the source of most of the leak. (The other two verified
> > valgrind
> > leaks are known, but not serious. One is in the yacc parser which is
> > only
> > called once at startup, and the other is a structure that is also only
> > allocated once at startup. )
> // Theo Schlossnagle
> // Principal Engineer -- http://www.omniti.com/~jesus/
> // OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
> // Ecelerity: fastest MTA on Earth
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users

Ryan W. Caudy
<rcaudy at gmail.com>
Bloomberg L.P.
<rcaudy1 at bloomberg.net>
<caudy at cnds.jhu.edu>         
Center for Networking and Distributed Systems
Department of Computer Science
Johns Hopkins University          

More information about the Spread-users mailing list