Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Jan 2004 01:46:59 -0600 (CST)
From:      Mike Silbersack <silby@silby.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: [CHECKER] bugs in FreeBSD
Message-ID:  <20040119014059.H85911@odysseus.silby.com>
In-Reply-To: <200401182238.i0IMcQYZ097543@apollo.backplane.com>
References:  <Pine.LNX.4.44.0401161607260.26554-100000@Xenon.Stanford.EDU> <200401181844.i0IIivlQ096389@apollo.backplane.com> <200401181957.i0IJvFTe096883@apollo.backplane.com> <200401182157.i0ILvNQe097287@apollo.backplane.com> <200401182238.i0IMcQYZ097543@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help


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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040119014059.H85911>