From owner-freebsd-current Tue Oct 6 21:05:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA27965 for freebsd-current-outgoing; Tue, 6 Oct 1998 21:05:43 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA27928 for ; Tue, 6 Oct 1998 21:05:35 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id XAA26673; Tue, 6 Oct 1998 23:05:21 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id XAA16469; Tue, 6 Oct 1998 23:04:50 -0500 Message-ID: <19981006230449.27474@right.PCS> Date: Tue, 6 Oct 1998 23:04:49 -0500 From: Jonathan Lemon To: Chuck Robey Cc: Alex , current Subject: Re: Something else seems to be leaking... References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: ; from Chuck Robey on Oct 10, 1998 at 09:14:10PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Oct 10, 1998 at 09:14:10PM -0400, Chuck Robey wrote: > On Tue, 6 Oct 1998, Alex wrote: > > > Welp. I finally got aorund to toying with kcminfo (some obscure thing > > from KDE), and it's leaking like a sieve. Naturally I think that it's to > > blame, however I've managed to narrow it down to a few lines of code > > (which have been reported to not leak on -stable): > > > > /* Q&D hack for swap display. Borrowed from xsysinfo-1.4 */ > > if ((pipe = popen("/usr/sbin/pstat -ks", "r")) == NULL) { > > used = total = 1; > > return; > > } > > pclose(pipe); This leak appears to be caused due to the interactions between vfork() and execl(), both inside the popen call. To wit: - vfork is called, - the child calls execl(), - which then calls buildargv(), which realloc()s space for the argv string. since we are sharing the address space with our parent, the parent also gets a copy. - the child calls execve(), leaving garbage in the parent's address space. I would guess that this was broken at some point when vfork() changed its semantics to have full address space sharing. The fix would be to either not use RFMEM for vfork() (as is done in the SMP case), or change buildargv to use alloca, and put the argv on the stack, which is not shared with the parent. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message