From jeremyp@gsmx07.alcatel.com.au Mon Mar  1 14:48:07 1999
Return-Path: <jeremyp@gsmx07.alcatel.com.au>
Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10])
	by hub.freebsd.org (Postfix) with ESMTP id 6B2C51552D
	for <FreeBSD-gnats-submit@FreeBSD.ORG>; Mon,  1 Mar 1999 14:47:51 -0800 (PST)
	(envelope-from jeremyp@gsmx07.alcatel.com.au)
Received: by border.alcanet.com.au id <40336>; Tue, 2 Mar 1999 09:36:11 +1100
Message-Id: <99Mar2.093611est.40336@border.alcanet.com.au>
Date: Tue, 2 Mar 1999 09:47:24 +1100
From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>
Reply-To: peter.jeremy@alcatel.com.au
To: FreeBSD-gnats-submit@FreeBSD.ORG
Cc: jeremyp@gsmx07.alcatel.com.au
Subject: memory leak in setenv(3)
X-Send-Pr-Version: 3.2

>Number:         10341
>Category:       bin
>Synopsis:       memory leak in setenv(3)
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar  1 14:50:01 PST 1999
>Closed-Date:    Thu Jan 27 08:14:55 PST 2000
>Last-Modified:  Thu Jan 27 08:19:30 PST 2000
>Originator:     Peter Jeremy
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
Alcatel Australia Limited
>Environment:

	setenv.c 1.4

>Description:

	When setenv() is called with overwrite == 1 (eg via putenv()),
	the environment variable already exists and the new value is
	larger than the old value, a new environment object is
	allocated (with malloc(3)) and the current object becomes
	inaccessible.

	Repeated calls to putenv(3) updating the same environment variable
	with different value sizes results in objects being successively
	allocated without being freed.

	[The problem showed up because I have an application which needs to
	convert times across multiple timezones, which requires the `TZ'
	environment variable to be regularly changed]

>How-To-Repeat:

	main()
	{
		while (1) {
			putenv("XXX=yy");
			putenv("XXX=yyy");
		}
	}

	compile, run and watch the process size grow :-(

>Fix:

	1) Add the restriction that the actual string passed to putenv(3)
	   will be stored in the environment (and therefore must stay in
	   scope) - most other Unices (and The Open Group's Single Unix
	   Specification) have this restriction.  This will remove the
	   need for putenv(3)/setenv(3) to use malloc(3) to duplicate the
	   passed variable.
	2) Keep a static bitmap of malloc'd environment strings (as
	   against statically passed strings) within setenv(3).  This
	   would allow space for re-defined variables to be realloc'd,
	   rather than being orphaned.

	Fix (1) may break FreeBSD code which relies on the FreeBSD
	semantics, though it shouldn't affect portable code (which
	presumably complies with the putenv(3) restrictions on other
	variants).  Fix (2) is messier.

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.ORG, peter.jeremy@alcatel.com.au
Cc:  
Subject: Re: bin/10341: memory leak in setenv(3)
Date: Tue, 2 Mar 1999 20:33:19 +1100

 >>Synopsis:       memory leak in setenv(3)
 >...
 >	[The problem showed up because I have an application which needs to
 >	convert times across multiple timezones, which requires the `TZ'
 >	environment variable to be regularly changed]
 
 I think there is already a PR by archie about this (with incomplete or
 wrong fixes attached).  IIRC, it is impossible to fix completely, since
 some callers keep pointers into the environment, so the environment
 can't be realloc()ed.
 
 Bruce
 

From: hoek@freebsd.org
To: freebsd-gnats-submit@freebsd.org, peter.jeremy@alcatel.com.au
Cc:  
Subject: Re:bin/10341:memoryleakinsetenv(3)
Date: Sun, 20 Jun 1999 09:15:54 -0400 (EDT)

 > I think there is already a PR by archie about this (with incomplete or
 
 Yes, bin/5604.  There may also be additional discussion on the -bugs
 list that did not get filed in the audid-trail of bin/5604.
 
 
State-Changed-From-To: open->closed 
State-Changed-By: ru 
State-Changed-When: Thu Jan 27 08:14:55 PST 2000 
State-Changed-Why:  
Duplicate of PR bin/5604. 
>Unformatted:
