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

[Theo Schlossnagle]

On Aug 31, 2004, at 2:19 PM, David Shaw wrote:
> I've attached a program that does that.  Running this program causes
> spread's memory and fd usage to shoot upwards.  The fd count stops at
> 511, but by that time, spread has most of the physical ram on the box.
> When the program finishes, spread's fd count eventually falls, but the
> memory is not released.  I suppose this could be extraordinarily
> agressive caching, but leak or cache, spread is ending up with far too
> much memory.

Are you talking about the RSS?  It is unlikely for the RSS to ever 
reduce.  UNIX heaps grow up.  So if I malloc 1GB, then malloc 1bytes, 
then free the 1GB, my RSS won't shrink.

I'm not sure why it takes a while for the fd count to go down.  But the 
real test is if you let the fd count go back down and then rerun the 
test, does the RSS grow any further?

> From earlier comments on the list, I wonder if the problem is messages
> (in this case, membership messages) that are waiting to be read by the
> client, but instead the client just disconnects.  These messages can
> never be delivered at this point, since the client is gone.
>
> What happens to messages that are waiting to be read by a client if
> that client disconnects?

they should be disposed of.

// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: fastest MTA on Earth