From owner-freebsd-hackers Thu Sep 18 14:20:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA07658 for hackers-outgoing; Thu, 18 Sep 1997 14:20:42 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA07634; Thu, 18 Sep 1997 14:20:33 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id OAA13921; Thu, 18 Sep 1997 14:19:52 -0700 (MST) From: Terry Lambert Message-Id: <199709182119.OAA13921@usr03.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 18 Sep 1997 21:19:51 +0000 (GMT) Cc: phk@critter.freebsd.dk, gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-Reply-To: <11017.874607149@time.cdrom.com> from "Jordan K. Hubbard" at Sep 18, 97 11:25:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@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! :( Ask them for a port. What the hell, the worst that could happen is they'd say "no". > 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. :-) Heh. mprotect must operate on pages. See my related suggestion... I didn't specify the mechanism (mprotect is the way it would be done). > 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. > > 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! :-) SIGBUS is kind of broken. THe typical way is that thee is a struct passed to the signal handler that isn't defined by POSIX, just like SIGWINCH. Sheesh. I guess I'm now the AntiPOSIX. 8-|. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.