From owner-freebsd-current Fri Aug 7 22:50:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA04010 for freebsd-current-outgoing; Fri, 7 Aug 1998 22:50:29 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA04005 for ; Fri, 7 Aug 1998 22:50:28 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id BAA165048; Sat, 8 Aug 1998 01:50:21 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <199808072155.OAA05409@bubba.whistle.com> References: from Garance A Drosihn at "Aug 7, 98 04:39:37 pm" Date: Sat, 8 Aug 1998 01:54:19 -0400 To: Archie Cobbs From: Garance A Drosihn Subject: Re: memory leaks in libc Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 2:55 PM -0700 8/7/98, Archie Cobbs wrote: >Garance A Drosihn writes: >> setenv("NAME","VAL1"); -> does a malloc to store NAME >> keep = getenv("NAME"); -> returns a pointer to the middle >> of that malloc'ed area >> setenv("NAME","VAL2"); -> replaces the value of NAME as >> is kept in the environment >> if ( ! strcmp(keep, "VAL1") ) { do_stuff(); } > > Yes, I think we can boil it down to this. If you call this a > perfectly valid program, then we should not fix the memory leak. > > If you call this a bug not worth accomodating, then we should > fix the memory leak. No. I'm saying that it's not worth stirring up potential trouble for every program which calls setenv(), in order to solve a memory leak problem which is not significant for 99.9% of those programs. Changing setenv() will only help programs which: 1) use setenv for manipulating the environment (as opposed to using putenv, or just going in and mucking with **environ by themselves). 2) make a *lot* of calls to setenv, such that the memory leak will amount to more space than the memory overhead you are going to add to setenv by tracking malloc's. 3) is making a lot of setenv calls to set the *same* variable, to different values of different length, because if each call is setting a different variable then there is no space you can free. > Isn't there a POSIX spec for getenv()/putenv()... what does > it say? Not in any of the references I have (which isn't saying much, I only have a few...). Most of the unix references that I have don't even list *any* of these routines in their index. (reminder: I only have a few...) Basically, I can't help but thing that if you add up all the memory on all the programs running on my machine right now, it's going to amount to maybe 4 kilobytes. I'd rather stay with that known leak-factor, then rewrite the API's for setenv and see what unknown side-effects that will have. But if someone really thinks this causes a serious memory leak, a leak that uses up significantly more memory than your improved implementation will use up in tracking these malloc'ed pointers, that's fine with me to. I'm just saying that if it were me, there's a long list of other projects that I'd worry about first. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message