Date: Thu, 18 Sep 1997 17:45:57 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Graham Wheeler <gram@cdsec.com> Cc: hackers@freebsd.org, freebsd-bugs@freebsd.org, gram@gram.cdsec.com.dk.tfs.com (Graham Wheeler) Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <7198.874597557@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 18 Sep 1997 16:51:33 %2B0200." <199709181451.QAA00397@cdsec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199709181451.QAA00397@cdsec.com>, Graham Wheeler writes: >Hi Poul and others > >This is a preliminary report, as it is still very early and the results >we are seeing may be coincidental. >I'll follow up on this in the morning (South African time) - if the >process is still running smoothly this would suggests that there >may be a problem with the malloc/free code in libc. Well, you'll still have to do more to convince me. The fact that two malloc implementations act differently is no proof of one of them being wrong, the different policies they use can make a bit difference in the outcome for errors in the main code. Imagine this: char *p = malloc(12); char *q = malloc(12); p[12] = 'B'; In the case of phkmalloc you have written into padding space, in the case of many other mallocs you have just destroyed the "back" pointer for the *q allocation. The results are very different. Another very common mistake is to trust the storage returned to contain zero bytes. Try the following 3 experiments: 1 set the 'A' flag to phkmalloc. 2 set the 'J' flag to phkmalloc. 3 set the 'Z' flag to phkmalloc. If they are any different in behaviour, they your code has a problem. Remember to keep fd#2 open to a logfile. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7198.874597557>