Date: Mon, 03 Oct 2005 11:31:34 -0600 From: Scott Long <scottl@samsco.org> To: Nate Lawson <nate@root.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, Olivier Houchard <cognet@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ddb db_command.c db_output.c Message-ID: <43416AF6.7010908@samsco.org> In-Reply-To: <43416038.6020701@root.org> References: <200510022257.j92MvV4N007297@repoman.freebsd.org> <20051003094732.H71864@fledge.watson.org> <43416038.6020701@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43416AF6.7010908>