From owner-freebsd-bugs Tue Jan 28 17:40:14 2003 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A00437B406 for ; Tue, 28 Jan 2003 17:40:13 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAB9543F75 for ; Tue, 28 Jan 2003 17:40:12 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id h0T1eCNS074838 for ; Tue, 28 Jan 2003 17:40:12 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id h0T1eCnF074837; Tue, 28 Jan 2003 17:40:12 -0800 (PST) Date: Tue, 28 Jan 2003 17:40:12 -0800 (PST) Message-Id: <200301290140.h0T1eCnF074837@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: David Schultz Subject: Re: bin/47599: Memory leak on stdout Reply-To: David Schultz Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR bin/47599; it has been noted by GNATS. From: David Schultz To: Sean Farley Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/47599: Memory leak on stdout Date: Tue, 28 Jan 2003 17:39:41 -0800 Thus spake Sean Farley : > On Tue, 28 Jan 2003, David Schultz wrote: > > > Thus spake Sean C. Farley : > > > When testing an application for memory leaks, I noticed one that > > > I could not get rid of. I happened to be allocated from > > > /usr/src/lib/libc/stdio/makebuf.c on line 72, but only when > > > printf() (or really any function) used stdout. Adding an > > > fclose(stdout) to the end of my application fixed the memory > > > leak. > > > > > > I realize this is not much of a leak, but I thought it would be > > > nice to have it either documented or fixed before others run > > > into this confusing leak. > > > > I don't think it's a bug that libc lazily allocates memory for the > > three standard file descriptors. I think you should consider this a > > false positive from dmalloc. > > Do you mean lazily deallocates memory? I think the allocation is > perfectly fine. I was just wondering if there is a point at which libc > was supposed to free the memory before exit. A hook similar to > atexit()? No, it lazily allocates a buffer for each output stream the first time that stream is used. It frees the buffer when the file is closed, which is usually never, in the case of the standard three file descriptors. In a practical sense, freeing that memory is pointless extra work because you need it until the program terminates anyway. If you just want to appease dmalloc, you could probably hack something up, but it would be harder than you think. You can't just special case the standard file descriptors and give them static buffers, because then setbuf(3) would cause a *real* memory leak. Adding an atexit hook might work, but you have a chicken-and-egg problem. Your hook to free up to three measely 1K buffers would have to be last, because other atexit routines would expect stdio to work. But dmalloc uses an atexit hook to look for memory leaks, so you'd have to run your atexit handler before dmalloc's. But dmalloc uses stdio... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message