From owner-freebsd-hackers Mon Sep 22 13:08:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA15269 for hackers-outgoing; Mon, 22 Sep 1997 13:08:17 -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 NAA15230 for ; Mon, 22 Sep 1997 13:08:09 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id WAA05206; Mon, 22 Sep 1997 22:07:58 +0200 (MET DST) Message-ID: <19970922220757.30317@bitbox.follo.net> Date: Mon, 22 Sep 1997 22:07:57 +0200 From: Eivind Eklund To: Terry Lambert Cc: hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) References: <19970922113306.60050@bitbox.follo.net> <199709221941.MAA18135@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69e In-Reply-To: <199709221941.MAA18135@usr06.primenet.com>; from Terry Lambert on Mon, Sep 22, 1997 at 07:41:55PM +0000 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 22, 1997 at 07:41:55PM +0000, Terry Lambert wrote: > Seeing that the list has looped does not guarantee that you know > where the last valid entry, or first invalid entry, exists. Agreed. And neither do anything else, except storing extra copies of all pointers somewhere where they can't be overwritten. > I don't even agree that your method actually finds the list loop, unless > you somhow guarantee that the loop goes back to the had such that your > pointer comparison is valid. (I assume you mean 'head' where you write 'had') Read the code again. It work by having two pointers walking the list, one fast and one slow. When the slow pointer intersect with the fast pointer, you know that you have a loop. And the slow pointer _will_ intersect the fast one if you have a loop and the datastructure isn't modified during the execution of your code - it follow the exact same set of links as the fast one, just at half the speed. As for the advanced diagonstics you want - sure, they look nice. However, I've implemented this kind of diagnostics before, and as long as I've exposed the invariant routine so it can be run at any point in the program, I've never needed or had benefit from them. I've found sprinkling the program with invariant checks at strategic points to be much more effective at exposing problems. Eivind.