backtrace() and the console log (was Re: cvs commit:
Greg 'groggy' Lehey
grog at FreeBSD.org
Wed Jan 21 18:11:32 PST 2004
On Thursday, 22 January 2004 at 12:43:40 +1100, Bruce Evans wrote:
> On Thu, 22 Jan 2004, Greg 'groggy' Lehey wrote:
>> On Wednesday, 21 January 2004 at 16:40:46 +1100, Bruce Evans wrote:
>>> On Tue, 20 Jan 2004, Nate Lawson wrote:
>>>> On Wed, 21 Jan 2004, Ian Dowse wrote:
>>>>> I've been using the following patch for a while to get backtrace()
>>>>> to output to the kernel message buffer. Sending all ddb output via
>>>>> printf might be undesirable for some cases, but I guess having it
>>>>> configurable with a `debug.ddb_use_printf' sysctl that defaults to
>>>>> the old behaviour would be ok?
>>> It's undesireable in almost all cases, since it fills up the message
>>> buffer with garbage.
>> If it's "garbage", why are we ever producing it? Currently I'm
>> getting a lot of LORs which don't get reported anywhere. I'd really
>> like to catch this "garbage".
> Because it is hard to debug when the debugger doesn't print any output.
> In almost all cases, you don't want to record all the false trails that
> you followed tracking down a problem, especially since any recording might
> cycle more important records out of the message buffer before syslogd(8)
> has a chance to run.
Ah, OK. You're talking about the complete ddb output. I was talking
about automatically generated backtraces. Agreed, you don't want to
be reminded of the roundabout way you get to a solution.
See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20040122/efb32b1f/attachment-0001.bin
More information about the cvs-all