From owner-cvs-src@FreeBSD.ORG Mon Oct 3 17:38:49 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61FF316A41F; Mon, 3 Oct 2005 17:38:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA6A843D73; Mon, 3 Oct 2005 17:38:42 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id DF07446B91; Mon, 3 Oct 2005 13:38:41 -0400 (EDT) Date: Mon, 3 Oct 2005 18:38:41 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Nate Lawson In-Reply-To: <43416038.6020701@root.org> Message-ID: <20051003180251.J92333@fledge.watson.org> References: <200510022257.j92MvV4N007297@repoman.freebsd.org> <20051003094732.H71864@fledge.watson.org> <43416038.6020701@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Olivier Houchard , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ddb db_command.c db_output.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 17:38:49 -0000 On Mon, 3 Oct 2005, Nate Lawson wrote: >> 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. Actually, there's an important feature difference here is that you get something that is potentially much more useful/persistent in the long run. To make use of a kernel core dump, you need a gdb version that understands the target architecture, a compiled kernel that matches the core, source that matches the kernel, etc. In absense of these things, the core is a pile of bytes that, with a high level of effort, you can try to extract data from -- especially if it was built months or years ago. The idea behind these mini dumps is that because you're in the kernel run-time environment and the dump generating code is compiled with the kernel that crashed, it can actually do some of the interpretation and data extraction up front, providing many of the details needed for a bug report without requiring use of gdb, kernel compiles, source trees, and so on. Sure, you'll need those things if you want to get back to line numbers, so it's not a substitute for a full dump, but it would be quite handy. I debug very few problems using a full dump, in part because they are so inconvenient to deal with -- it's hardly ever the size, it's the complexity of trying to get architectures, source versions, kernel configurations, etc, aligned. Robert N M Watson