From owner-freebsd-current Thu Aug 6 11:16:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA22090 for freebsd-current-outgoing; Thu, 6 Aug 1998 11:16:10 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21994 for ; Thu, 6 Aug 1998 11:15:57 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id VAA28889; Thu, 6 Aug 1998 21:13:30 +0300 (EEST) Date: Thu, 6 Aug 1998 21:13:30 +0300 (EEST) From: Narvi To: Bruce Evans cc: syko@sykotik.org, dg@root.com, freebsd-current@FreeBSD.ORG, freebsd@xaa.iae.nl Subject: Re: memory leaks in libc In-Reply-To: <199808061636.CAA00012@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 7 Aug 1998, Bruce Evans wrote: > >Apache uses them quite frequently. And this could make it very costly on > >large webservers. Where I work, we have hundreds of connections to some > >of our webservers per minute. We also use cgi scripts very frequently, > >and these use *env* functions quite frequently as well. > > The env functions are already costly. They use dumb linear searches > and malloc(), and don't alloc a little more than necessary so that the > environment can grow a little without reallocation. Garbage collection > need not be equally pessimal. > > Bruce > Ok, I did make a dumb suggestion already. What follows is just my cursory reading of the code and thoughts on it: As we cannot disallow user r/w access to the environment that by-passes *env functions in the libc, we cannot have a perfect world. In a way, it is similar to allowing the user do go and muck freely with the malloc internal structures. But it should be possible to have a schema under wich: a) there exists a hash of all pointers returned by malloc to us. Using it we can know which strings are safe to be reallocated/freed b) a hash of all setenved strings. For use by get/setenv. Fragmentation: use one malloced area per a name, value pair. Keep an additional adaptive anmount of memory for the case it is going to get expanded yet again. Which adds the problem: the environment would need to be captured at startup time, before any user code runs, that would set up the inital hashes (init_environ). BUGS: Can be made to leak both memory and spam it's internal pointer hash, if the user a) setenvs a variable, b) manually changes the pointer value in the array c) repeats a) and b) a lot. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message