Date: Thu, 6 Aug 1998 13:56:40 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: dg@root.com, Mark Huizer <freebsd@xaa.iae.nl> Cc: freebsd-current@FreeBSD.ORG Subject: Re: memory leaks in libc Message-ID: <v0401171cb1ef86eecc10@[128.113.24.47]> In-Reply-To: <199808060948.CAA26488@implode.root.com> References: Your message of "Thu, 06 Aug 1998 10:08:59 %2B0200." <19980806100859.A312@xaa.iae.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
>> To mention a very simple example:
>>
>> main(){while(1){setenv("A","AA",1);setenv("A","A",1);}}
>>
>> will consume all memory within short periods of time (see setenv.c
>> for the reason).
>>
>> Is this wellknown? I think it is bad, and would like to fix it
>
> 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.
setenv could keep track of memory that *it* mallocs for environment
variables. That would at least solve the example case, even if it
doesn't solve everything. This implies it'd have some memory-
management smarts of it's own, and I don't know if a partial fix is
really worth that much effort, but I would think it is doable.
(seeing that it's mostly dealing with short strings, I'd have it malloc
1 Kbytes at a time, and then carve that up for environment variables.
Then it wouldn't be too expensive to check if a given variable is part
of setenv's own memory).
---
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?v0401171cb1ef86eecc10>