From owner-freebsd-hackers Fri Sep 19 00:19:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA20631 for hackers-outgoing; Fri, 19 Sep 1997 00:19:37 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA20598 for ; Fri, 19 Sep 1997 00:19:30 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id JAA21632; Fri, 19 Sep 1997 09:24:43 +0200 (SAT) Received: by citadel via recvmail id 21630; Fri Sep 19 09:24:36 1997 by gram.cdsec.com (8.8.5/8.8.5) id JAA01726; Fri, 19 Sep 1997 09:10:29 +0200 (SAT) From: Graham Wheeler Message-Id: <199709190710.JAA01726@cdsec.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: nate@mt.sri.com (Nate Williams) Date: Fri, 19 Sep 1997 09:10:28 +0200 (SAT) Cc: hackers@freebsd.org In-Reply-To: <199709181811.MAA13376@rocky.mt.sri.com> from "Nate Williams" at Sep 18, 97 12:11:25 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi guys > True, but I think Graham's arguement puts the ball in your court. Yes, > it's *possible* that a bug in his code exists, but given that his other > malloc has debugging capabilities built-in, one could argue that the > burden of proof is now on PHK-malloc. Perhaps not yet - but if I try (say) three other malloc libraries, and there is no problem with any of them, then I would say that there is a reasonable case to be made. I think Poul's defense is quite correct; using just one other library is inconclusive. > Graham, does your software run on a Solaris or HP/UX box? If so, you > may consider getting an evaluation copy of Purify and running it against > your code. IMHO, Purify is the *best* single-tool for pointing out these > kinds of errors, aside from good programming practices. I find it even > more useful than a debugger for 'hard to find' errors, although when > coupled with a debugger it's usefulness is second to none. Unfortunately not - it requires kernel modifications to the BPF code... -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/