From owner-freebsd-current@FreeBSD.ORG Sun Aug 3 23:12:53 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D91137B401 for ; Sun, 3 Aug 2003 23:12:53 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2A9B43FA3 for ; Sun, 3 Aug 2003 23:12:51 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h746CYmQ001098; Sun, 3 Aug 2003 23:12:34 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h746CWWW001097; Sun, 3 Aug 2003 23:12:32 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 3 Aug 2003 23:12:32 -0700 From: David Schultz To: "Ryan T. Dean" Message-ID: <20030804061232.GA873@HAL9000.homeunix.com> Mail-Followup-To: "Ryan T. Dean" , freebsd-current@freebsd.org References: <3F2BAC6B.3040606@cytherianage.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F2BAC6B.3040606@cytherianage.net> cc: freebsd-current@FreeBSD.ORG Subject: Re: vfprintf() has a 4096-byte memory leak? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2003 06:12:53 -0000 On Sat, Aug 02, 2003, Ryan T. Dean wrote: > "Poul-Henning Kamp" wrote: > >In message <3F2B9C59.3060209 at cytherianage.net > >>, "Ryan T. > >Dean" writes: > >>/Hey all- > /> >/ I was doing some app debugging tonight, and noticed what appears > to /> >/be a memory leak in vfprintf(). > /> > >This is probably the buffer which stdio uses for all I/O. > > > >Try calling > > setbuf(stdout, NULL); > > setbuf(stderr, NULL); > > > >as the very first thing in your program, and you will probably see > >that it does not allocate the 4k buffer, you may also be able to > >measure the performance change due to this. > > > >In other words, what you see is perfectly normal, and to be expected, > >but if it is a problem for you, the above is the workaround. > > Aha. setbuf(stdout, NULL); does prevent the buffer from being allocated. > However, in the case of stdout and stderr, if you don't setbuf() it to > null, a buffer is malloc'd. The corresponding free() is in fclose. So, if > you [f]printf() to stdout/stderr, and fclose(stdout/stderr), you are fine. > If, however, you don't know that buffers are being allocated for > stdin/stdout and don't fclose() or setbuf() to NULL, a 4096-byte chunk of > memory is allocated and never freed. For shits and giggles, I checked a > DeadRat 8 box - no buffering by default. I guess the only reason I'm > worried is the > potential number of programs in the ports tree originally written on a > system > where stdout/stderr behave differently, or people (like myself) who didn't > have a clue any sort of output buffering was enabled on stdout/stderr, and > as a result have memory leaks. If the porter did their job, it shouldn't > be an issue (was caught, patched, and the patch submitted upstream), but, > then, we never know, right? stdio's buffering routines make a one-time allocation for their buffers, and this memory does not get freed because it can potentially get used during the entire time the program is running. This isn't a bug. See the archives for details.