Date: Fri, 19 Sep 1997 02:10:43 +0200 (MET DST) From: Eivind Eklund <perhaps@yes.no> To: Graham Wheeler <gram@cdsec.com> Cc: phk@critter.freebsd.dk, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <199709190010.CAA07340@bitbox.follo.net> In-Reply-To: Graham Wheeler's message of Thu, 18 Sep 1997 18:06:51 %2B0200 (SAT) References: <7198.874597557@critter.freebsd.dk> <199709181606.SAA00506@cdsec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > >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. > > I'll do my best... ;-) > > > 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. > > Agreed. > > > > > 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. > > The debug libmalloc that I am now using uses the following layout for > an allocated block: > > | prevlink | nextlink | size | memspace | size | > > i.e. the size is stored both immediately preceding and immediately > following the useable space. As part of the consistency checking, > these two sizes are compared and should match. This should catch almost > all small overruns or underruns, and abort the process. So this > malloc should be less tolerant of bugs in my code than pkhmalloc is, > rather than more tolerant, Try running efence (not in the ports-collection - I'll remedy that). This little gem of a program add a non-accessible page after or before your allocation (both at the same time is not possible), and will give you a core dump the moment you do an invalid access. I've used it to debug large programs for others before; I fortunately haven't needed it since I switched to FreeBSD, and thus don't know how easy it compile here. It compiled cleanly on SGI and Linux, at least. ftp://ftp.science.unitn.it/pub/unix/programming/libraries/efence-2.04.tar.gz Eivind.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709190010.CAA07340>