Date: Sun, 01 Feb 1998 18:20:44 -0800 (PST) From: Jonathan Hanna <pangolin@rogers.wave.ca> To: Jonathan Hanna <pangolin@rogers.wave.ca> Cc: (Dave Bodenstab) <imdave@mcs.net>, freebsd-bugs@FreeBSD.ORG, Archie Cobbs <archie@whistle.com> Subject: Re: bin/5604: memory leak and other bugs in setenv(3) Message-ID: <XFMail.980201182044.pangolin@rogers.wave.ca> In-Reply-To: <XFMail.980201174853.pangolin@rogers.wave.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <pangolin@rogers.wave.ca>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980201182044.pangolin>