From owner-freebsd-hackers Fri Sep 12 14:16:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09662 for hackers-outgoing; Fri, 12 Sep 1997 14:16:03 -0700 (PDT) Received: from usr08.primenet.com (tlambert@usr08.primenet.com [206.165.6.208]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA09644 for ; Fri, 12 Sep 1997 14:15:59 -0700 (PDT) Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA25502; Fri, 12 Sep 1997 14:15:34 -0700 (MST) From: Terry Lambert Message-Id: <199709122115.OAA25502@usr08.primenet.com> Subject: Re: Memory leak in getservbyXXX? To: julian@whistle.com (Julian Elischer) Date: Fri, 12 Sep 1997 21:15:34 +0000 (GMT) Cc: mike@smith.net.au, gram@cdsec.com, hackers@FreeBSD.ORG In-Reply-To: <3419A0D8.7DE14518@whistle.com> from "Julian Elischer" at Sep 12, 97 01:06:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > 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 > > they aren't using the threaded libc are they? Exactly my thought as well... To the user: you should note that the threaded libc differs from the standard libc in that, instead of returning pointers to function modified static data areas, most functions which formerly did just that now return allocated buffers which contain the results, and it is now the user's responsibility to free these buffers. The use of static data buffers in libc is a long-standing abomination, blessed by ANSI and codified in stone by POSIX. Assume any man page which states a pointer to a static data area is returned is actually allocating a data area and expecting the caller to free it, whenever you are using a thread-safe library. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.