From owner-freebsd-hackers  Fri Sep 12 05:59:09 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA01245
          for hackers-outgoing; Fri, 12 Sep 1997 05:59:09 -0700 (PDT)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA01232
          for <hackers@freebsd.org>; Fri, 12 Sep 1997 05:58:58 -0700 (PDT)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id WAA02951;
	Fri, 12 Sep 1997 22:26:47 +1000 (EST)
Message-Id: <199709121226.WAA02951@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Graham Wheeler <gram@cdsec.com>
cc: hackers@freebsd.org
Subject: Re: Memory leak in getservbyXXX? 
In-reply-to: Your message of "Sat, 12 Sep 1997 14:16:53 +0200."
             <199709121216.OAA20310@cdsec.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 12 Sep 1997 21:56:46 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > If it's a memory leak then it sounds like it's inside the stdio 
> > library, possibly in fopen()/fclose().  Without more data it's going to 
> > be hard to track this one.  
> 
> Tell me about it 8-(
> 
> It does seem like a memory leak, as the memory use reported by top grows
> over time. I have memory allocation debugging code which confirms that
> I have no leaks in my code (at least of C++ objects), and the fact that
> older sites have been running for months seems to confirm this. 

OK.  More to the point then it sounds like it's a memory leak due to 
some change in stdio.  That's getting slightly easier to chase I guess.

> > If you have a forgiving customer, it would be immensely useful to build 
> > a copy of libc with debugging symbols and link your binary static, and 
> > then have the user run that until it dies.
> 
> I may have to do this, and give them a new kernel with kernel trace support
> compiled in. But this is quite tricky - they're about 1000 miles away, and
> don't have the skills to do a kernel update themselves, so it will be a last
> resort.

You wouldn't have to do anything more than supply them with a new 
executable; once you had the app in a the runaway state, get a core 
from it and bring it back.  You would want to be interested in the 
state of the FILE buffer pool inside the stdio library (obviously you 
will need to keep your local symbols!) particularly.

If you were going to be more adventurous, I would make a point of 
logging all calls to __smakebuf() in the stdio guts, and doing some 
tracking on the buffers it allocates; they're supposed to be freed in 
fclose().  This is going to mean a fairly chunky logfile, but if you 
help us run this one down we will be _very_ grateful!

> Well, it could at least give a good indication if it is in fact the calls
> to getservbyXXX that are the cause of the problem.

I think you may have found a very subtle bug in the stdio library 
(unless you are poking it with a bad pointer).

mike