From owner-freebsd-hackers  Wed Aug 13 15:54:28 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id PAA04858
          for hackers-outgoing; Wed, 13 Aug 1997 15:54:28 -0700 (PDT)
Received: from implode.root.com (implode.root.com [198.145.90.17])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA04847;
          Wed, 13 Aug 1997 15:54:23 -0700 (PDT)
Received: from implode.root.com (localhost [127.0.0.1])
	by implode.root.com (8.8.5/8.8.5) with ESMTP id PAA18976;
	Wed, 13 Aug 1997 15:55:32 -0700 (PDT)
Message-Id: <199708132255.PAA18976@implode.root.com>
To: Terry Lambert <terry@lambert.org>
cc: julian@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject: Re: 2.2.2+ crash.. more info 
In-reply-to: Your message of "Wed, 13 Aug 1997 09:34:38 PDT."
             <199708131634.JAA12554@phaeton.artisoft.com> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Wed, 13 Aug 1997 15:55:32 -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>>    Quite likely. It's fairly easy to have a bug where a resource is exhausted
>> (usually memory) in a subroutine called from an interrupt routine, resulting
>> in a tsleep() if the call to malloc isn't M_NOWAIT.
>
>Is there any way we could talk you into adding an #ifdef DIAGNOSTIC
>to malloc to catch this case?

   To catch which case? malloc() doesn't know a whole lot about the state of
the system; it especially doesn't have knowledge about how interrupts work
and whether or not it is okay sleep. I don't know if we have a way of
knowing this even if we did want to add such machine-dependant checks to
malloc(). In any case, the checks would be best added to tsleep(), not to
malloc().

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project