From owner-freebsd-bugs Thu Sep 18 11:27:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA25424 for bugs-outgoing; Thu, 18 Sep 1997 11:27:13 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA25415; Thu, 18 Sep 1997 11:27:10 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id LAA11021; Thu, 18 Sep 1997 11:25:50 -0700 (PDT) To: Poul-Henning Kamp cc: Graham Wheeler , hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Thu, 18 Sep 1997 18:24:04 +0200." <10531.874599844@critter.freebsd.dk> Date: Thu, 18 Sep 1997 11:25:49 -0700 Message-ID: <11017.874607149@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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. Man, I sure wish there was a copy of purify available for FreeBSD. It's great at catching stuff like this! :( Maybe you could hack free() to do an mprotect(addr, len, PROT_NONE) on free'd pages, unprotecting them again as necessary when the malloc routines themselves need to frob that memory. Or, since we're just testing, do it from an internally registered SIGBUS handler which figures out the right thing to do. :-) BTW, how *do* you get the faulting memory location from a SIGBUS handler? I was just playing around with this a bit and noted that it wasn't immediately obvious how you'd get that info from the signal handler. Jordan P.S. I also noticed that processes which catch SIGBUS will dump incomplete core files - only the first 8K is dumped. Sounds like a bug to me and I think we should either dump the whole thing or not dump core at all rather than producing a truncated and rather useless core file! :-)