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

[David Shaw]

On Mon, Aug 30, 2004 at 09:32:24PM -0400, Jonathan Stanton wrote:
> Hi David,
>   
> 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
> 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. )
>     
> I should have remembered this earlier, but awhile ago someone reported a
> leak in the skiplist code and it was fixed (and committed to cvs). You can
> find the discussion in the spread-users archive. That fix occured after
> 3.17.2 was released. You have a cvs account, so if you could check out of
> cvs and check if the leak still occurs, I'm hopeful you will find it is
> already fixed.

I am now testing with the CVS code and indeed the join/leave leak
seems to be fixed.  Excellent!

Unfortunately, there is still something that looks like a leak
somewhere in the CVS code.  Specifically, I can get basically all the
memory on a box if I do:

Repeat 600 times:
   {
     Connect w/membership messages

     Repeat 500 times:
        {
         Join a group
         Leave a group
        }

     Disconnect
   }

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.

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

David
-------------- next part --------------
#include <stdio.h>
#include <sp.h>

int main(int argc,char *argv[])
{
  int mbox,err,i,j;
  char myself[MAX_GROUP_NAME];

  for(j=0;j<600;j++)
    {
      err=SP_connect(NULL,NULL,0,1,&mbox,myself);
      if(err!=ACCEPT_SESSION)
	{
	  printf("Spread error %d on connect\n",err);
	  break;
	}

      for(i=0;i<500;i++)
	{
	  char groupname[MAX_GROUP_NAME];

	  sprintf(groupname,"%d",i);
	  err=SP_join(mbox,groupname);
	  if(err<0)
	    {
	      printf("Spread error %d on join\n",err);
	      break;
	    }

	  err=SP_leave(mbox,groupname);
	  if(err<0)
	    {
	      printf("Spread error %d on leave\n",err);
	      break;
	    }
	}

      err=SP_disconnect(mbox);
      if(err!=0)
	{
	  printf("Spread error %d on disconnect\n",err);
	  break;
	}

      printf("Count %d\n",j);
    }

  /* Never reached */
  return 0;
}