Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 May 2003 17:08:23 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        freebsd-current@freebsd.org
Subject:   Re: LOR with -current
Message-ID:  <20030511170706.F74671@gamplex.bde.org>
In-Reply-To: <20030510141840.Q2955@gamplex.bde.org>
References:  <20030508.124929.74756191.haro@kgt.co.jp> <20030508.102242.72244093.imp@bsdimp.com> <20030508.111836.130233489.imp@bsdimp.com> <20030510141840.Q2955@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
[Resending with trimmed Cc: after second bounce]

On Thu, 8 May 2003, M. Warner Losh wrote:

> In message: <16058.36990.299231.566625@grasshopper.cs.duke.edu>
>             Andrew Gallatin <gallatin@cs.duke.edu> writes:
> :
> : M. Warner Losh writes:
> :  > That reminds me, would anybody object if I were to hack traceback so
> :  > that it would actually put the traceback in the dmesg buffer when not
> :  > called from ddb?

Yes.  No hacks please.  See old mail about how to implement this not
very hackishly (basically s/db_printf/printf/g, and change printf to
act like the old db_printf iff db_active is set; this would also fix
the bug of forgetting to use db_printf in ddb commands and reduce the
bugs for abusing non-ddb commands as ddb commands).

> : FWIW, I think that tracebacks generated from DDB_TRACE should also
> : go into the dmesg buffer.  It would save quite a few initial exchanges
> : with users..

I think that DDB_TRACE shouldn't have been committed until it did this.

> Does anybdoy know why the ddb output doesn't go into the dmesg buffer
> in general?  It sure would save me a lot of grief as well if it did.

Yes.
1. The message buffer (and some other aspects of printf() as opposed to
   db_printf()) is highly non-reentrant and lock-deficient.  This is
   broken in general.  printf() can panic when it is called in certain
   not very unusual contexts, and ddb is often needed in these contexts.
   Also, using ddb in the relatively unusual context of debugging the
   message buffer itself would cause unbounded recursion if ddb output
   always went to the message buffer.
2. ddb output tends to be large and not very useful.  It can push normal
   kernel messages (not to mention ddb messages) out of the message buffer
   before they can be seen by syslog.

Just thought of another problem: the traceback can trap if it gets confused
about the stack frame and/or the number of args.  In ddb context, these
traps are handled properly using setjmp() (except trap() barfs about them
unsafely and unusefully using ordinary printf before it reenters ddb).
This safety harness is missing if the traceback is done outside of ddb.
You really don't want debugging messages about a problem compounding
the problem.

Bruce



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