From nobody@www.freebsd.org  Fri Jun 14 15:57:24 2002
Return-Path: <nobody@www.freebsd.org>
Received: from nwww.freebsd.org (www.FreeBSD.org [216.136.204.117])
	by hub.freebsd.org (Postfix) with ESMTP id E71D837B401
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 14 Jun 2002 15:57:23 -0700 (PDT)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by nwww.freebsd.org (8.12.2/8.12.2) with ESMTP id g5EMvNhG093587
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 14 Jun 2002 15:57:23 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.2/8.12.2/Submit) id g5EMvNLO093586;
	Fri, 14 Jun 2002 15:57:23 -0700 (PDT)
Message-Id: <200206142257.g5EMvNLO093586@www.freebsd.org>
Date: Fri, 14 Jun 2002 15:57:23 -0700 (PDT)
From: Nathan Mower <nmower@verio.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Memory leak in setenv
X-Send-Pr-Version: www-1.0

>Number:         39314
>Category:       misc
>Synopsis:       Memory leak in setenv
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jun 14 16:00:12 PDT 2002
>Closed-Date:    Sat Jun 15 02:41:49 PDT 2002
>Last-Modified:  Sat Jun 15 02:50:01 PDT 2002
>Originator:     Nathan Mower
>Release:        4.4, 4.5, 4.6-RC, 5
>Organization:
NTT/Verio
>Environment:
FreeBSD hostname 4.4-RELEASE FreeBSD 4.4-RELEASE #1: Wed Jan 23 11:05:43 MST 2002 root@hostname:/usr/src/sys/compile/WHATEVER  i386
>Description:
      There is a memory leak in setenv in the case where a name/value pair already exists and the new value is larger than the old one.  Setenv does not free the old memory before it malloc's space for the new string.
>How-To-Repeat:
      setenv("HOME", "/usr/home/abc", 1);
      setenv("HOME", "/usr/home/abcdefghijklmnopqrstuvwxyz", 1);
>Fix:
      free the old environ[offset] before malloc'ing the new one.
>Release-Note:
>Audit-Trail:

From: David Greenman-Lawrence <dg@root.com>
To: Nathan Mower <nmower@verio.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/39314: Memory leak in setenv
Date: Sat, 15 Jun 2002 00:44:45 -0700

 >>Description:
 >      There is a memory leak in setenv in the case where a name/value pair already exists and the new value is larger than the old one.  Setenv does not free the old memory before it malloc's space for the new string.
 >>How-To-Repeat:
 >      setenv("HOME", "/usr/home/abc", 1);
 >      setenv("HOME", "/usr/home/abcdefghijklmnopqrstuvwxyz", 1);
 >>Fix:
 >      free the old environ[offset] before malloc'ing the new one.
 
    This is a well known and unfixable problem. The problem is that
 environment data may not (and often is not) allocated by malloc - you
 just don't know, so you can't free it. This is mentioned in the BUGS
 section in the setenv.3 manual page, although the description of 
 the problem is misleading.
 
 -DG
 
 D.G.Lawrence
 Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500
 TeraSolutions, Inc. - http://www.terasolutions.com - (503) 288 9544
 The FreeBSD Project - http://www.freebsd.org
 Pave the road of life with opportunities.
State-Changed-From-To: open->closed 
State-Changed-By: dougb 
State-Changed-When: Sat Jun 15 02:41:10 PDT 2002 
State-Changed-Why:  

This is a known limitation of setenv. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39314 

From: Bruce Evans <bde@zeta.org.au>
To: Nathan Mower <nmower@verio.net>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: misc/39314: Memory leak in setenv
Date: Sat, 15 Jun 2002 19:47:17 +1000 (EST)

 On Fri, 14 Jun 2002, Nathan Mower wrote:
 
 > >Description:
 >       There is a memory leak in setenv in the case where a name/value pair already exists and the new value is larger than the old one.  Setenv does not free the old memory before it malloc's space for the new string.
 > >How-To-Repeat:
 >       setenv("HOME", "/usr/home/abc", 1);
 >       setenv("HOME", "/usr/home/abcdefghijklmnopqrstuvwxyz", 1);
 > >Fix:
 >       free the old environ[offset] before malloc'ing the new one.
 
 Easier said than done.  Patches to free it in previous PRs about this were
 not accepted, IIRC because it was considered too dangerous to free memory,
 since this would turn pointers previously returned by getenv() into garbage.
 setenv() is now specified in a standard that seems to permit freeing
 (POSIX.1-2001), so it might be time to revisit these patches.
 
 Bruce
 
>Unformatted:
