From owner-freebsd-hackers Wed Aug 13 17:12:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA09257 for hackers-outgoing; Wed, 13 Aug 1997 17:12:12 -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 RAA09250 for ; Wed, 13 Aug 1997 17:12:09 -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 RAA19915; Wed, 13 Aug 1997 17:13:24 -0700 (PDT) Message-Id: <199708140013.RAA19915@implode.root.com> To: Terry Lambert cc: hackers@FreeBSD.ORG Subject: Re: 2.2.2+ crash.. more info In-reply-to: Your message of "Wed, 13 Aug 1997 17:02:20 PDT." <199708140002.RAA15802@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 13 Aug 1997 17:13:24 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >On second thought, it's a bad idea to put it in tsleep() instead >of malloc(); the driver calling a malloc() which could tsleep() >is in error, in any case. Putting the test in tsleep() would only >mask the error in the case the malloc *might* sleep, but didn't. >You really want to catch erroneous use of API's (like this) with >DIAGNOSTIC -- regardless of runtime cost involved. Actually, the sleep isn't called from malloc(), but rather from a lower level VM system routine, but this doesn't affect the point you are making, which I think is a good one. >Anyway, it was just a thought -- after Mike Smith talked about >spending a year tracking one down, it seems a small penalty, even >if the ISR dispatcher has to set a flag on entry and exit to make >it possible to catch. Since it's only DIAGNOSTIC, I'm not concerned >about the expense. I see that Julian committed something for this, but I don't know what yet. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project