Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Oct 2002 15:23:08 +0200
From:      Dag-Erling Smorgrav <des@ofug.org>
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
Message-ID:  <xzpof9hbagz.fsf@flood.ping.uio.no>
In-Reply-To: <20021026040625.U4817-100000@gamplex.bde.org> (Bruce Evans's message of "Sat, 26 Oct 2002 04:14:57 %2B1000 (EST)")
References:  <20021026040625.U4817-100000@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




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