# Kernel debugging. For the first time.



## Marcin Solski (Apr 13, 2016)

Hello All!

Background: I have just experienced sudden reboot but luckily vmcore.0 has been saved in /var/crash. I was using custom kernel (maybe trimmed to much) but without debugging support while the reboot took place.

I was trying to do some basic debugging and to do so I have recompiled my kernel adding only "makeoptions DEBUG=-g" to my config file. Having kernel.debug and vmcore.0 I tried to use kgdb(1) but the only thing it gives me is 'cannot access memory'.

Is it possible to debug this problem using this method or I need to replicate this issue while running debugging enabled kernel? In other words, is current vmcore.0 usable (it was saved by system running kernel with disabled debugging)?


----------



## SirDice (Apr 13, 2016)

Have a look here: Developer's Handbook: Chapter 10. Kernel Debugging.


----------



## Marcin Solski (Apr 13, 2016)

Yes, I went through it yesterday evening but I'm lacking experience.

My case isn't standard as I wasn't running debug-enabled kernel at the time of crash and once I build one afterwards it doesn't work with vmcore.0 file. I got stuck having developer's handbook :-|...


----------



## SirDice (Apr 13, 2016)

I'm not much of a programmer so I can't help out with the details but those core dumps are really only useful if they contain debug information. Your previous core dump doesn't have it so it's not very useful. The handbook should also show how to increase the debug information, after that it's a matter of trying to reproduce the crash. The core dump that gets made then will have the necessary debug information.


----------



## Juha Nurmela (Apr 13, 2016)

There are some symbols in non-debug case too, good for function call traces etc. But you already knew that, of course

Juha


----------

