From owner-freebsd-current Thu Aug 6 10:53:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA18122 for freebsd-current-outgoing; Thu, 6 Aug 1998 10:53:13 -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 KAA18107 for ; Thu, 6 Aug 1998 10:53:10 -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 NAA97020; Thu, 6 Aug 1998 13:52:41 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <199808060948.CAA26488@implode.root.com> References: Your message of "Thu, 06 Aug 1998 10:08:59 +0200." <19980806100859.A312@xaa.iae.nl> Date: Thu, 6 Aug 1998 13:56:40 -0400 To: dg@root.com, Mark Huizer 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 >> 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