[an error occurred while processing this directive] FreeBSD Handbook : Kernel Debugging : Post-mortem analysis of a dump
Previous: Debugging a kernel crash dump with kgdb
Next: On-line kernel debugging using DDB

15.2. Post-mortem analysis of a dump

What do you do if a kernel dumped core but you did not expect it, and it's therefore not compiled using config -g? Not everything is lost here. Don't panic!

Of course, you still need to enable crash dumps. See above on the options you've got in order to do this.

Go to your kernel compile directory, and edit the line containing COPTFLAGS?=-O. Add the -g option there (but don't change anything on the level of optimization). If you do already know roughly the probable location of the failing piece of code (e.g., the pcvt driver in the example above), remove all the object files for this code. Rebuild the kernel. Due to the time stamp change on the Makefile, there will be some other object files rebuild, for example trap.o. With a bit of luck, the added -g option won't change anything for the generated code, so you'll finally get a new kernel with similar code to the faulting one but some debugging symbols. You should at least verify the old and new sizes with the size(1) command. If there is a mismatch, you probably need to give up here.

Go and examine the dump as described above. The debugging symbols might be incomplete for some places, as can be seen in the stack trace in the example above where some functions are displayed without line numbers and argument lists. If you need more debugging symbols, remove the appropriate object files and repeat the kgdb session until you know enough.

All this is not guaranteed to work, but it will do it fine in most cases.


FreeBSD Handbook : Kernel Debugging : Post-mortem analysis of a dump
Previous: Debugging a kernel crash dump with kgdb
Next: On-line kernel debugging using DDB [an error occurred while processing this directive]