Date: Tue, 2 Mar 1999 09:47:24 +1100 From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> To: FreeBSD-gnats-submit@FreeBSD.ORG Cc: jeremyp@gsmx07.alcatel.com.au Subject: bin/10341: memory leak in setenv(3) Message-ID: <99Mar2.093611est.40336@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
>Number: 10341
>Category: bin
>Synopsis: memory leak in setenv(3)
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Mar 1 14:50:01 PST 1999
>Closed-Date:
>Last-Modified:
>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:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Mar2.093611est.40336>