Harald Schmalzbauer wrote:
> Bob Bishop wrote:
> > See
> > http://www.uk.freebsd.org/doc/en_US.ISO8859-1/books/developers-han
> > dbook/kerneldebug.html,
> > particularly 17.4 and 17.5
>
> Thank you for that link, but that's far too complicated for me. I don't know
> any of these gdb commands, I can just feed you with info.
>
> So as far as I understand, if I enter "trace" at any point when I see "db>"
> that's what you need is it?
The trace information that this will give is only marginally
useful for debugging, and then only if the problem does not
involve a dereference of a bad pointer or a lock inversion,
or some other issue that would require eyballing a particular
line of code and the code that surrounds it in order to find
the problem.
For anything more complicated than that, we need line numbers.
There are three ways to get this from a crashed machine:
1) Remote source level debugging from another machine;
this requires that you have a copy of the build tree
for what's running on the machine that crashed
2) Local source level debugging using a crashdump; this
requires that you enable crash dumps, and that you
have a copy of the build tree for what's running on
the machine that crashed
3) You must be running a -RELEASE, so that *we* have a
copy of the build tree for what's running on the
machine that crashed, and you must transcribe *exactly*
all the information from the traceback
Option 3 is nearly impossible, unless someone sends you a kernel
to try and run, since the release distribution doesn't enable
ddb at build time, and there's no way to enable it at boot time
as a seperate option (but it works OK for Darwin, which provides
a stack traceback by hexadecimal address, if you enable the
verbose crash dumps at boot time).
FreeBSD really needs to either ship with DDB enabled, provide a
way for DDB to be enabled in a release at boot time, or find a
way of providing a minimal stack traceback (even if it's just a
list of hex addresses, like Darwin) at crash time.
In any case, this will not help diagnose problems resulting from
someone stomping memory and/or bad pointer dereferences, or those
arising from missing locks, etc..
Your best bet, if you want useful help with a complex problem is
to learn how to provide the more complicated crash information
which is needed in order to remotely diagnose complex problems.
-- Terry
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
