From owner-freebsd-bugs Sun Feb 1 18:22:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA16344 for freebsd-bugs-outgoing; Sun, 1 Feb 1998 18:22:17 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from pc-21490.bc.rogers.wave.ca (pc-21490.bc.rogers.wave.ca [24.113.51.240]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA16338 for ; Sun, 1 Feb 1998 18:22:16 -0800 (PST) (envelope-from jh@pc-21490.bc.rogers.wave.ca) Received: (from jh@localhost) by pc-21490.bc.rogers.wave.ca (8.8.7/8.8.7) id SAA02583; Sun, 1 Feb 1998 18:20:44 -0800 (PST) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 01 Feb 1998 18:20:44 -0800 (PST) Reply-To: Jonathan Hanna Organization: Pangolin Systems From: Jonathan Hanna To: Jonathan Hanna Subject: Re: bin/5604: memory leak and other bugs in setenv(3) Cc: (Dave Bodenstab) , freebsd-bugs@FreeBSD.ORG, Archie Cobbs Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-bugs" On 02-Feb-98 Jonathan Hanna wrote: > > On 01-Feb-98 Archie Cobbs wrote: >> Dave Bodenstab writes: >>>... 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]). >> > > Is there a problem with just checking that the address is higher up the stack? > For threaded environments is there a reliable way of determining that > an address is on the original stack? If not, should malloc have an entry > point to ask it if it owns something? Oops, ignore the stack nonsense, and even malloc cannot help. Nasty. Jonathan Hanna