Date: Sat, 8 Aug 1998 01:54:19 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Archie Cobbs <archie@whistle.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: memory leaks in libc Message-ID: <v04011706b1f12c4741b4@[128.113.24.47]> In-Reply-To: <199808072155.OAA05409@bubba.whistle.com> References: <v04011702b1f10c76c658@[128.113.24.47]> from Garance A Drosihn at "Aug 7, 98 04:39:37 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04011706b1f12c4741b4>