Date: Sun, 1 Feb 1998 23:18:40 -0800 (PST) From: Archie Cobbs <archie@whistle.com> To: pangolin@rogers.wave.ca Cc: imdave@mcs.net, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/5604: memory leak and other bugs in setenv(3) Message-ID: <199802020718.XAA05015@bubba.whistle.com> In-Reply-To: <XFMail.980201182044.pangolin@rogers.wave.ca> from Jonathan Hanna at "Feb 1, 98 06:20:44 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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. -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?199802020718.XAA05015>