Re: consoles, client, and memory leaks

[ On Friday, June 7, 2002 at 10:40:25 (-0700), Bryan Stansell wrote: ]
> Subject: consoles and memory leaks (was Re: How many consoles?)
>
> On Fri, Jun 07, 2002 at 12:02:29PM -0400, Greg A. Woods wrote:
> > That said, as you can see above there's still a very serious memory
> > leak somewhere, and that'll drastically affect scalability in any
> > production system....  The second conserver process is allocating an
> > additional 1.2KB or so with every client connection (I have a cron job
> > that makes console client connections to collect data from my three UPS
> > units once every minute).
> 
> hmmm...i just did a test with 7.2.2 (and i don't know why it would be
> different with 7.2.1) by having conserver manage five consoles.  i then
> did:
> 
>     i=1; while true; do (echo "echo $1"; sleep 1) | \
>     ~/./conserver/playpen/conserver-7.2.2/console/console bash; \
>     i=$((i + 1)); done
> 
> it's currently spewing:
> 
>     underdog (root) 288:# [Enter `^Ec?' for help]
>     echo 287
>     287
>     underdog (root) 289:# 
> 
> and still going.  the memory size hasn't grown at all (using both pmap
> and ps to check sizes - solaris here).  i also have a redhat 7.3 system
> running the same test - just started it up.  it's up to 109 connections
> and there hasn't been a change in memory usage, according to ps.

Well I've finally upgraded to 7.2.2 and re-integrated my 'chat' patches,
but I'm still seeing the memory leak on my good old NetBSD-1.3.2 server.

After re-jigging the debug output in many places, and keeping much more
careful track of when file descriptors are created and closed, I've
finally narrowed it down to somewhere in the massive Kiddie() function
(or something it calls) in the "MAIN" while(1) loop.  It looks like its
closer to an ~2KB increase for every client connection.  I can't see any
obvious problems yet though.  it looks like all the file descriptors are
getting closed properly and so on.  All the new chat code is quiescent
during this time too.

I'm going to link against libefence and/or libvmalloc and see if I can't
pin it down....

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>