Date: Sun, 1 Feb 1998 15:48:41 -0800 (PST) From: Archie Cobbs <archie@whistle.com> To: imdave@mcs.net (Dave Bodenstab) Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/5604: memory leak and other bugs in setenv(3) Message-ID: <199802012348.PAA03303@bubba.whistle.com> In-Reply-To: <199802011957.NAA02253@base486.home.org> from Dave Bodenstab at "Feb 1, 98 01:57:29 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Dave Bodenstab writes: > > From: Archie Cobbs <archie@whistle.com> > > There is a memory leak in the setenv() function. If you overwrite > > a value with a longer value, the memory allocated for the shorter > > value is never freed. > > This is ``the way it is'' as long as I can recall (from system 5 > release 2 in the early 80's.) This is because the initial environment > values and environ[] array are created by the kernel when a process's > address space is created by the exec(2) system call. Take a look > at /usr/src/libc/csu/i386/crt0.c and /usr/src/sys/kern/kern_exec.c. > These areas are not on malloc's memory lists, therefore it is > illegal to call free with any of these addresses. Unless setenv > were changed to keep a record of which environ[] elements had been > malloc'ed by a previous call to setenv, there is no way to know if > it is OK to call free(). Your fix to setenv makes an illegal call > to free -- change your test program to: Yes.. I didn't think of this until after submitting the bug. I think the only way to stop the leak is by keeping a list of the actual pointers returned from calls to malloc() and realloc() (rather than a binary array, because user code can modify environ[x]). I'll try to come up with a more correct patch. Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802012348.PAA03303>