Date: Thu, 6 Aug 1998 21:13:30 +0300 (EEST) From: Narvi <narvi@haldjas.folklore.ee> To: Bruce Evans <bde@zeta.org.au> Cc: syko@sykotik.org, dg@root.com, freebsd-current@FreeBSD.ORG, freebsd@xaa.iae.nl Subject: Re: memory leaks in libc Message-ID: <Pine.BSF.3.96.980806203948.9173G-100000@haldjas.folklore.ee> In-Reply-To: <199808061636.CAA00012@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980806203948.9173G-100000>