From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 23:47:03 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0EB616A4CE for ; Sun, 18 Jan 2004 23:47:03 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 51B0E43D58 for ; Sun, 18 Jan 2004 23:47:02 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 65395 invoked from network); 19 Jan 2004 07:47:00 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 19 Jan 2004 07:47:00 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 19 Jan 2004 01:46:59 -0600 (CST) From: Mike Silbersack To: Matthew Dillon In-Reply-To: <200401182238.i0IMcQYZ097543@apollo.backplane.com> Message-ID: <20040119014059.H85911@odysseus.silby.com> References: <200401181844.i0IIivlQ096389@apollo.backplane.com> <200401181957.i0IJvFTe096883@apollo.backplane.com> <200401182157.i0ILvNQe097287@apollo.backplane.com> <200401182238.i0IMcQYZ097543@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: [CHECKER] bugs in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2004 07:47:03 -0000 On Sun, 18 Jan 2004, Matthew Dillon wrote: > Well, this is fun. There are over 460 files in the 5.x source tree > (360 in DFly) that make calls to malloc(... M_NOWAIT), and so far > about 80% of the calls that I've reviewed generate inappropriate > side effects when/if a failure occurs. CAM is the biggest violator... > it even has a few panic() conditionals if a malloc(... M_NOWAIT) fails. > Not Fun! I keep getting the urge to write a simple failure generator for malloc / m_get / etc that would compare the caller's address to a linked list of previous callers so that you could ensure that you would get exactly one failure returned to malloc() call in the system. This would guarantee better coverage than random failures, which aren't likely to find the bulk of the failure cases. Another interesting debug idea would be to extend the above idea, and have seperate malloc buckets for each caller, along with cookies / canary values before and after each piece of data; this could be used to figure out *exactly* which function is causing memory corruption. Of course, I found so many problems when I wrote the MBUF_STRESS_TEST code that I really don't want to think about how long fixing all the bugs exposed by the above two tests would take. Mike "Silby" Silbersack