From owner-freebsd-current Thu Aug 6 23:58:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA09684 for freebsd-current-outgoing; Thu, 6 Aug 1998 23:58:44 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from USC-FW.utimaco.co.at (mail-gw.utimaco.co.at [195.96.28.162]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA09678 for ; Thu, 6 Aug 1998 23:58:39 -0700 (PDT) (envelope-from Michael.Schuster@utimaco.co.at) Received: (from uucp@localhost) by USC-FW.utimaco.co.at (8.8.8/8.8.8) id IAA01459; Fri, 7 Aug 1998 08:57:18 +0200 (CEST) (envelope-from Michael.Schuster@utimaco.co.at) Received: from ns1.int.utimaco.co.at(10.1.0.254) by USC-FW.utimaco.co.at via smap (V2.0) id xma001457; Fri, 7 Aug 98 08:56:58 +0200 Received: from utimaco.co.at (ultra1.int.utimaco.co.at [10.1.0.32]) by safeconcept.int.utimaco.co.at (8.8.5/8.8.5) with ESMTP id IAA16388; Fri, 7 Aug 1998 08:56:56 +0200 (CEST) Message-ID: <35CAA537.BEE345B8@utimaco.co.at> Date: Fri, 07 Aug 1998 08:56:55 +0200 From: Michael Schuster Organization: Utimaco Safe Concept GmbH. Linz Austria X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "current@FreeBSD.ORG" , Narvi Subject: Re: memory leaks in libc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Apart from what everybody else has already said arguing for or against doing something about this, I do have a comment: Narvi 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 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