cvs commit: src/sys/ddb db_command.c db_output.c

[Scott Long]

Nate Lawson wrote:
> Robert Watson wrote:
> 
>> On Sun, 2 Oct 2005, Olivier Houchard wrote:
>>
>>> cognet      2005-10-02 22:57:31 UTC
>>>
>>>  FreeBSD src repository
>>>
>>>  Modified files:
>>>    sys/ddb              db_command.c db_output.c
>>>  Log:
>>>  - Call db_setup_paging() for traceall.
>>>  - Make it so one can't call db_setup_paging() if it has already been 
>>> called
>>>  before. traceall needs this, or else the db_setup_paging() call from
>>>  db_trace_thread() will reset the printed line number, and override its
>>>  argument.
>>>  This is not perfect for traceall, because even if one presses 'q' 
>>> while in
>>>  the middle of printing a backtrace it will finish printing the 
>>> backtrace
>>>  before exiting, as db_trace_thread() won't be notified it should 
>>> stop, but
>>>  it is hard to do better without reworking the pager interface a lot 
>>> more.
>>
>>
>>
>> Thanks!
>>
>> Is there any chance I can interest you in an idea phk, I, and a few 
>> others have been kicking around for a bit relating to smart small 
>> dumps? Specifically, we were discussing the idea of allowing a dumping 
>> mode in which rather than dumping all of kernel memory, we dump 
>> specifically the common and useful output from ddb, such as ps, show 
>> locked vnods, show alllocks, traceall, show allpcpu, and so on, 
>> basically in text format, to the dump partition.  Then the results can 
>> be pulled off easily in a format that is appropriate for e-mailing or 
>> submitting via a PR, even without a full debugging kernel, etc.  Among 
>> other things, these dumps would be much, much smaller than a memory 
>> dump, meaning they could be kept around like log files 
>> (/var/log/crash.log.0, ...), be e-mailed to the sysadmin, etc.  It 
>> would require some new magic in DDB and the dumping code, but almost 
>> all of the logic to generate the information from DDB could be reused, 
>> perhaps via an alternative pager or debug output device :-).
> 
> 
> That's fine as a hack-around, but I hope that doesn't distract effort 
> from sparse kernel dumps.  If you throw out non-anonymous pages, buffer 
> cache, etc., you end up with a very small image to begin with.  Add in 
> gzip compression and it wouldn't be much larger than your uncompressed 
> logs.  Then you can run whatever info tools you want against the core 
> since no actual data is lost.
> 

Well, what Robert is talking about isn't really a 'dump' in the sense of 
using kgdb, it's more 'run every debugger command available and capture 
the output to disk' =-)  I can't recall if I've sent email on this 
before, but it would be neat if we had the following levels of dump:

0: all RAM
1: all KVM
2: all proc, thread, and pcb data

Scott