From owner-freebsd-bugs  Thu Sep 18 17:11:10 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA20043
          for bugs-outgoing; Thu, 18 Sep 1997 17:11:10 -0700 (PDT)
Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20004;
          Thu, 18 Sep 1997 17:10:58 -0700 (PDT)
Received: (from eivind@localhost)
	by bitbox.follo.net (8.8.6/8.8.6) id CAA07340;
	Fri, 19 Sep 1997 02:10:43 +0200 (MET DST)
Date: Fri, 19 Sep 1997 02:10:43 +0200 (MET DST)
Message-Id: <199709190010.CAA07340@bitbox.follo.net>
From: Eivind Eklund <perhaps@yes.no>
To: Graham Wheeler <gram@cdsec.com>
CC: phk@critter.freebsd.dk, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
In-reply-to: Graham Wheeler's message of Thu, 18 Sep 1997 18:06:51 +0200 (SAT)
Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?)
References: <7198.874597557@critter.freebsd.dk>
	<199709181606.SAA00506@cdsec.com>
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> > >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.