extract panic message & debugging from vmcore.0 ?

[Mark Millard]

On 2017-Jun-29, at 7:12 PM, Michael W. Lucas <mwlucas at michaelwlucas.com> wrote:

> Short question: how do I get debug information for a PR from a vmcore?
> 
> Long question: we have conflicting docs. Which should I follow?
> 
> Good news: I needed a panic for the new "Absolute FreeBSD" anyway,
> this one will do.
> 
> Details:
> 
> I got an actual kernel panic by running "gpart resize" on:
> 
> FreeBSD storm 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r318747: Tue May 23 16:27:01 EDT 2017     root at storm:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> I dumped it at the panic prompt, savecore ran at boot. According to
> the Handbook, the next step is to run "kgdb kernel.debug vmcore.0" to
> recover the panic message. But no kgdb is installed.

Look for /usr/libexec/kgdb .

But for some, most, or all TARGET_ARCH's the
FreeBSD folks now recommend using kgdb from
ports. (Which you built and installed.)

/usr/libexec/kgdb is more for means-of-last-resort
use when one can not get to the point of having
the port kgdb around.

> After some searching, I installed devel/gdb.
> 
> # kgdb kernel.debug /var/crash/vmcore.0
> GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-portbld-freebsd12.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from kernel.debug...done.
> ABI doesn't support a vmcore target
> 
> Well, that's not good. I did more searching and found
> /usr/src/tools/debugscripts/README.
> 
> # cd /usr/obj/usr/src/sys/GENERIC
> # make gdbinit
> # gdb kernel.debug

Did you miss a /var/crash/vmcore.0 above?

> GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-portbld-freebsd12.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from kernel.debug...done.
> .gdbinit:16: Error in sourced command file:
> No symbol "remotebaud" in current context.

Unsure about the above.

Separately. . .

I'm no expert but you might need to pick
between the default minidump vs. a full
memory dump depending on purposes and what
information is to be extracted:

debug.minidump: 1
vs.
debug.minidump: 0

in the sysctl debug.minidump output. I
doubt that they are fully equivalent.

Of course a full memory dump implies
needing space ready to hold that full
copy.

===
Mark Millard
markmi at dsl-only.net