From owner-freebsd-bugs Mon Feb 2 07:59:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA18032 for freebsd-bugs-outgoing; Mon, 2 Feb 1998 07:59:46 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from base486.home.org (imdave@imdave.pr.mcs.net [205.164.3.77]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA18027 for ; Mon, 2 Feb 1998 07:59:43 -0800 (PST) (envelope-from imdave@mcs.net) Received: (from imdave@localhost) by base486.home.org (8.8.8/8.8.8) id JAA12210; Mon, 2 Feb 1998 09:59:33 -0600 (CST) Date: Mon, 2 Feb 1998 09:59:33 -0600 (CST) From: Dave Bodenstab Message-Id: <199802021559.JAA12210@base486.home.org> To: archie@whistle.com, pangolin@rogers.wave.ca Subject: Re: bin/5604: memory leak and other bugs in setenv(3) Cc: freebsd-bugs@FreeBSD.ORG, imdave@mcs.net Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-bugs" > Archie Cobbs wrote: > > Jonathan Hanna writes: > > > > 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. > > I like the idea of being able to ask the malloc() code if a pointer > is valid to call free() with... might have other uses. > I can't really think of a valid use for this -- except as a workaround for sloppy programming. In the case of setenv, the man page should probably mention the memory leak. If there were an application that required the modification of the environment as the test program in the original PR did, then one would have to ``do it by hand'' (ie. not use setenv.) There are times when the routines in the C library are not applicable for a given task. My $.02 Dave Bodenstab imdave@mcs.net