Date: Fri, 07 Aug 1998 08:56:55 +0200 From: Michael Schuster <Michael.Schuster@utimaco.co.at> To: "current@FreeBSD.ORG" <current@FreeBSD.ORG>, Narvi <narvi@haldjas.folklore.ee> Subject: Re: memory leaks in libc Message-ID: <35CAA537.BEE345B8@utimaco.co.at>
next in thread | raw e-mail | index | archive | help
Apart from what everybody else has already said arguing for or against doing something about this, I do have a comment: Narvi <narvi@haldjas.folklore.ee> wrote: > On Thu, 6 Aug 1998, Bruce Evans wrote: > > > > 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 ... > > a) allocate a bit more memory than needed > b) set the environment string > c) end it with zero > d) append a certain token after the end of the string saying "ok > to free() me" to anyone knowing what to look at? > > But couldn't a string end at the end of allocated area so that by peeking > behind the final zero we will sometimes cause a SIGSEV? Why not put the token into the beginning of the malloc'd memory and increase the value of the returned pointer by a constant number? This saves you the variable search effort for the terminating zero and also guards better against accidental overwrites. something like: /* define TOKEN to be an 8-byte unique pattern */ char *x; x = (char *) malloc (size); memcpy (x, TOKEN, sizeof (TOKEN)); x += sizeof (TOKEN); /* do env string copy into x; return x */ I did a small test program that seems to indicate that malloc always returns values 16-byte aligned (is that correct linguistically?). IFF we can rely on this behaviour, we could increment our (char) pointer by 8 (or 24 if 8 is not enough) bytes and check for this 8-byte displacement in setenv, even before having to check for the token. > > There is no love, no good, no happiness and no future - > all these are just illusions. maybe, but we live for them :-) Archie Cobbs <archie@whistle.com> wrote: >OK, just to prove I'm not lazy... try this. >+static void addhash(void *ptr); >+static void rmhash(void *ptr); (lots of stuff not quoted) I think that although my approach my be a bit less flexible, it certainly saves the second malloc (in the hash functions), and therefore would perform better. -- Michael Schuster 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?35CAA537.BEE345B8>