From owner-freebsd-bugs Sun Feb 1 15:49:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA29210 for freebsd-bugs-outgoing; Sun, 1 Feb 1998 15:49:25 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA29203 for ; Sun, 1 Feb 1998 15:49:24 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id PAA19501; Sun, 1 Feb 1998 15:48:49 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma019497; Sun Feb 1 15:48:41 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id PAA03303; Sun, 1 Feb 1998 15:48:41 -0800 (PST) From: Archie Cobbs Message-Id: <199802012348.PAA03303@bubba.whistle.com> Subject: Re: bin/5604: memory leak and other bugs in setenv(3) In-Reply-To: <199802011957.NAA02253@base486.home.org> from Dave Bodenstab at "Feb 1, 98 01:57:29 pm" To: imdave@mcs.net (Dave Bodenstab) Date: Sun, 1 Feb 1998 15:48:41 -0800 (PST) Cc: freebsd-bugs@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-bugs" Dave Bodenstab writes: > > From: Archie Cobbs > > 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