Date: Sun, 27 Oct 2002 14:21:38 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dag-Erling Smorgrav <des@ofug.org> 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: <20021027141325.U10013-100000@gamplex.bde.org> In-Reply-To: <xzpof9hbagz.fsf@flood.ping.uio.no>
index | next in thread | previous in thread | raw e-mail
On Sat, 26 Oct 2002, Dag-Erling Smorgrav wrote:
> 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().
Yes, though I would be tempted to optionally leave out the panic_hint part.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021027141325.U10013-100000>