Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Feb 1998 09:59:33 -0600 (CST)
From:      Dave Bodenstab <imdave@mcs.net>
To:        archie@whistle.com, pangolin@rogers.wave.ca
Cc:        freebsd-bugs@FreeBSD.ORG, imdave@mcs.net
Subject:   Re: bin/5604: memory leak and other bugs in setenv(3)
Message-ID:  <199802021559.JAA12210@base486.home.org>

next in thread | raw e-mail | index | archive | help
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802021559.JAA12210>