svn commit: r212964 - head/sys/kern

[John Baldwin]

On Tuesday, September 28, 2010 3:36:11 pm Pawel Jakub Dawidek wrote:
> On Tue, Sep 28, 2010 at 03:04:11PM -0400, John Baldwin wrote:
> > I'm suggesting they provide us the core.txt.X file, not the full minidump.
> > A developer could then ask them to run specific commands from a subsequent
> > kgdb session to obtain more details.
> 
> But you still will have your kernel memory dumped to disk. This is
> probably not a problem for most of the users, though.

I think that set of users is sufficiently small that they could choose a
non-default setting.

> > > You can always ask user to add this one-line to rc.conf to turn
> > > minidump on and provide you the info that was missing in textdump.
> > 
> > This only works for easily reproducible bugs, and in that case they can turn
> > on dumps later without a need for it to be automatic at all.
> 
> And I'm arguing that those are very rare situations where there is a
> bug, which is hard to reproduce and where textdump won't be of any help.

Actually, this can be quite common.  A stack trace alone can get you started,
but the ability to check the value and state of local variables at various
frames on the stack can be key to figuring out many panics.

I also tended to prefer DDB several years ago, but while working at a
large FreeBSD consumer with lots of machines, I found that many panics are
not, in fact, very reproducible.  Even for ones that are, the machine that
caused the issue may not be available for testing (it's a production
machine after all), so one has to make the most of post-mortem analysis and
not rely on repeatedly panic'ing a machine to debug issues.  In this case,
kgdb is far, far more useful than ddb.

None of us are smart enough to figure out all the things that ddb should
possibly dump in a textdump to handle every possible panic, but with kgdb
you can query new data after initial investigation of the problem.

-- 
John Baldwin