From owner-freebsd-bugs Thu Sep 18 09:24:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA16517 for bugs-outgoing; Thu, 18 Sep 1997 09:24:48 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA16498; Thu, 18 Sep 1997 09:24:40 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id SAA10533; Thu, 18 Sep 1997 18:24:04 +0200 (CEST) To: Graham Wheeler cc: hackers@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Sat, 18 Sep 1997 18:06:51 +0200." <199709181606.SAA00506@cdsec.com> Date: Thu, 18 Sep 1997 18:24:04 +0200 Message-ID: <10531.874599844@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709181606.SAA00506@cdsec.com>, Graham Wheeler writes: >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, again: depends. >Can you offer an explanation as to why the process never returns from >the call to malloc, nor does it abort? This seems to indicate an infinite >loop. Not having delved too deeply into your code, I can only speculate >that the linked list is being made circular, so the process is in an >infinite, looping traversal. Perhaps that is a check that can be added; >namely that walking the list must always proceed forward, never backward >(assuming that the list is kept in sequential order). This is about the only way you could get it to loop I think. That means that somebody wrote to memory malloc hadn't passed them (ie: your code). This would indicate a bug of the class where memory is written to after being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop."