From owner-freebsd-current Thu Aug 6 18:46:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA27309 for freebsd-current-outgoing; Thu, 6 Aug 1998 18:46:53 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA27277 for ; Thu, 6 Aug 1998 18:46:43 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id SAA08445; Thu, 6 Aug 1998 18:46:25 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd008412; Thu Aug 6 18:46:19 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA25783; Thu, 6 Aug 1998 18:46:10 -0700 (MST) From: Terry Lambert Message-Id: <199808070146.SAA25783@usr06.primenet.com> Subject: Re: memory leaks in libc To: nate@mt.sri.com (Nate Williams) Date: Fri, 7 Aug 1998 01:46:10 +0000 (GMT) Cc: dg@root.com, narvi@haldjas.folklore.ee, bde@zeta.org.au, freebsd@xaa.iae.nl, freebsd-current@FreeBSD.ORG In-Reply-To: <199808061447.IAA12240@mt.sri.com> from "Nate Williams" at Aug 6, 98 08:47:45 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The problem with fixing setenv() is that you don't know if a pointer > > was malloced, allocated from the env area above the stack, points to > > read-only text, points to a static data buffer, etc. There really is > > no way to know for sure, so you can't free the memory. [ ... ] > > You can know if you malloced it in a previous call to putenv() or setenv(). [ ... ] > > Perhaps Bruce is suggesting that a seperate array be allocated to keep > > track of whether or not an env pointer was malloced? This would be very > > costly and, IMO, not worth it considering how rarely memory is lost by > > not freeing previously malloced strings. > > Very costly? Could you do almost all of it in the userland libraries, > and would be pretty cost-free, especially considering it would only have > much effect if the user did lots of environment allocations? The easiest thing to do would be to, in crt0.o, set another envp (__envp?) to point to the the original envp. If they are not equal, then you realloc the space. Frankly, I'd rather just hang the think of the proc struct. It's the non-opaque accesses and the execve(2) insistance on an envp in a non-opaque format that screw you. You can still implement it, but you have to tread a fine line to do it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message