From owner-cvs-all  Sat Oct 26  6:23:22 2002
Delivered-To: cvs-all@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 70C2E37B401; Sat, 26 Oct 2002 06:23:21 -0700 (PDT)
Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 3E85F43E4A; Sat, 26 Oct 2002 06:23:15 -0700 (PDT)
	(envelope-from des@ofug.org)
Received: by flood.ping.uio.no (Postfix, from userid 2602)
	id 315BC534F; Sat, 26 Oct 2002 15:23:09 +0200 (CEST)
X-URL: http://www.ofug.org/~des/
X-Disclaimer: The views expressed in this message do not necessarily
  coincide with those of any organisation or company with
  which I am or have been affiliated.
To: Bruce Evans <bde@zeta.org.au>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	John Baldwin <jhb@FreeBSD.org>, <cvs-all@FreeBSD.org>,
	<cvs-committers@FreeBSD.org>
Subject: Re: cvs commit: src/sys/kern kern_mutex.c
References: <20021026040625.U4817-100000@gamplex.bde.org>
From: Dag-Erling Smorgrav <des@ofug.org>
Date: Sat, 26 Oct 2002 15:23:08 +0200
In-Reply-To: <20021026040625.U4817-100000@gamplex.bde.org> (Bruce Evans's
 message of "Sat, 26 Oct 2002 04:14:57 +1000 (EST)")
Message-ID: <xzpof9hbagz.fsf@flood.ping.uio.no>
Lines: 18
User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386--freebsd)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG

Bruce Evans <bde@zeta.org.au> writes:
> No need.  Memory access errors are very easy to debug since debuggers show
> a context with the precise instruction and function that caused the error.
> Anyone how can debug them doesn't need a hint about why the function might
> cause a memory access error.  Panics are not so easy to debug, since the
> context and restartability are messed up by calling panic().

Maybe the KASSERT macros could be rewritten to cause a trap rather
than call panic(), to avoid messing up the stack frame?

#define KASSERT(exp,msg) \
        do { if (!(exp)) panic_hint msg; *(int *)NULL = 0; } while (0)

panic_hint() would be a short wrapper for vsnprintf().

DES
-- 
Dag-Erling Smorgrav - des@ofug.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message