From zerium@zerium.dyn.ml.org  Sat Oct 10 07:18:27 1998
Received: from online.no (pilt-s.online.no [193.212.1.34])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA10917
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 10 Oct 1998 07:18:13 -0700 (PDT)
          (envelope-from zerium@zerium.dyn.ml.org)
Received: from zerium.dyn.ml.org (ti34a26-0012.dialup.online.no [130.67.65.140])
	by online.no (8.9.1/8.9.1) with ESMTP id QAA10151
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 10 Oct 1998 16:18:01 +0200 (MET DST)
Received: (from zerium@localhost)
	by zerium.dyn.ml.org (8.9.1/8.9.1) id TAA20293;
	Fri, 9 Oct 1998 19:40:04 +0200 (CEST)
	(envelope-from zerium)
Message-Id: <199810091740.TAA20293@zerium.dyn.ml.org>
Date: Fri, 9 Oct 1998 19:40:04 +0200 (CEST)
From: zerium@webindex.no
Reply-To: zerium@zerium.dyn.ml.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: popen/pclose leaks
X-Send-Pr-Version: 3.2

>Number:         8252
>Category:       bin
>Synopsis:       popen/pclose leaks
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Oct 10 07:20:01 PDT 1998
>Closed-Date:    Sun Nov 22 19:24:23 PST 1998
>Last-Modified:  Sun Nov 22 19:25:23 PST 1998
>Originator:     Hans Petter Bieker
>Release:        FreeBSD 3.0-BETA i386
>Organization:
>Environment:

FreeBSD XXXXXXXXXX 3.0-BETA FreeBSD 3.0-BETA #2: Thu Oct  8 03:33:05 \
CEST 1998 root@XXXXXXXXXX:/usr/src/sys/compile/ZERIUM  i386

>Description:

A pclose() after a popen does not free all the uses memory.

This is only a problem in v3.0, not in v2.2.x.

The RCS diff between the popen.c in v2.2 and v3.0 is null, nil, no,
nothing. I'm not sure if the libc function calls leaks or if it's a kernel
problem.

>How-To-Repeat:

#include <stdio.h>

int
main(argc, argv)
	int             argc;
	char           *argv[];
{
	for (;;) {
		FILE           *pfile;

		pfile = popen("true", "r");
		if (!pfile)
			break;
		if (pclose(pfile) == -1)
			break;
	}

	return 0;
}

run it and watch the process grow:
zerium 14211  0.0  0.6   804  452  v0  S+    5:56pm   0:00.06 myprocess
zerium 14211  4.9  0.8   948  596  v0  S+    5:56pm   0:00.23 myprocess
zerium 14211  5.3  1.1  1208  856  v0  S+    5:56pm   0:00.54 myprocess
zerium 14211  5.3  1.4  1500 1148  v0  R+    5:56pm   0:00.87 myprocess
zerium 14211  5.7  1.9  1860 1508  v0  S+    5:56pm   0:01.29 myprocess
zerium 14211  5.5  2.4  2228 1876  v0  S+    5:56pm   0:01.72 myprocess
zerium 14211  5.5  3.1  2832 2480  v0  S+    5:56pm   0:02.42 myprocess
zerium 14211  5.9  3.4  3076 2724  v0  S+    5:56pm   0:02.70 myprocess
zerium 14211  6.3  3.8  3372 3020  v0  S+    5:56pm   0:03.05 myprocess
zerium 14211  5.9  4.2  3712 3360  v0  S+    5:56pm   0:03.45 myprocess
                        ^^^^ ^^^^
>Fix:
	
N/A
>Release-Note:
>Audit-Trail:

From: Jonathan Lemon <jlemon@americantv.com>
To: zerium@zerium.dyn.ml.org
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/8252: popen/pclose leaks
Date: Sat, 10 Oct 1998 09:54:16 -0500

 This is a problem in the interaction between vfork() and execl().
 
 The new vfork semantics are such that the child uses the parent's
 address space, not COW.
 
 execl calls malloc() to build the correct argv vector to pass
 to execve.  This malloc'ed area used to be thrown away after 
 execve creates a new address space, but now hangs around in
 the parent's address space, creating a leak.
 
 Quick-n-dirty fix is to turn off fast vfork:
 
 	sysctl -w kern.kern_vfork=0
 
 A better fix would be to somehow release the malloc'd area on a
 call to execve().
 --
 Jonathan

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.ORG, zerium@webindex.no
Cc:  Subject: Re: kern/8252: popen/pclose leaks
Date: Sun, 11 Oct 1998 01:22:31 +1000

 >This is only a problem in v3.0, not in v2.2.x.
 >
 >The RCS diff between the popen.c in v2.2 and v3.0 is null, nil, no,
 >nothing. I'm not sure if the libc function calls leaks or if it's a kernel
 >problem.
 
 execl() leaks if vfork() is actually vfork().  Global data should not be
 changed between vfork() and execve(), but execl() calls malloc().  The
 simple fix (a tiny pessimization) is to replace vfork() by fork() in
 popen().
 
 Bruce

From: dag-erli@ifi.uio.no (Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?= )
To: zerium@zerium.dyn.ml.org
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/8252: popen/pclose leaks
Date: 10 Oct 1998 18:02:59 +0200

 zerium@webindex.no writes:
 > >Severity:       critical
 > >Priority:       high
 
 Hmm, are you sure this is appropriate?
 
 > A pclose() after a popen does not free all the uses memory.
 > 
 > This is only a problem in v3.0, not in v2.2.x.
 > 
 > The RCS diff between the popen.c in v2.2 and v3.0 is null, nil, no,
 > nothing. I'm not sure if the libc function calls leaks or if it's a kernel
 > problem.
 
 The leak is related to the use of vfork(). If you replace vfork() with
 fork() in src/lib/libc/gen/popen.c the bug will disappear.
 
 I have a feeling that calling execl() in the child branch of a vfork()
 might be a pretty bad idea, since execl() calls buildargv() which uses
 realloc() extensively.
 
 DES
 -- 
 Dag-Erling Smrgrav - dag-erli@ifi.uio.no
State-Changed-From-To: open->closed 
State-Changed-By: jkoshy 
State-Changed-When: Sun Nov 22 19:24:23 PST 1998 
State-Changed-Why:  
Fixed in rev 1.11 of "src/lib/libc/gen/popen.c" by peter. 
>Unformatted:
