# Kernel panics sometimes resulting in no core dump.



## umanwizard (Nov 5, 2019)

Hello, I am running 13-CURRENT (compiled recently from source using default build settings) and recently I have been kernel panics every so often. They can happen at any time but seem to be more likely when the system is running a graphical environment and is at high load (e.g., during `make -j64 buildworld`).

I have configured my system to collect core dumps: my swap partition is 50 GB (large enough to contain any conceivable minidump), `dumpon` reports that it is indeed configured as a dump partition, and I have `savecore_enable="YES"` in /etc/rc.conf. I also have the sysctl `debug.debugger_on_panic` set to 0, which seems to be necessary for core dumps to happen (instead of breaking into the debugger on panic). Before, when that sysctl was set to 1, my graphical environment would hand; now it reboots. The changing behavior depending on the value of `debug.debugger_on_panic` is what makes me think this really is a kernel panic, as opposed to some other possible issue that could cause a crash.

The weird thing is that when I manually cause a panic via `sudo sysctl debug.kdb.panic=1` , my system reboots as expected, and a core dump **does** get generated and saved in /var/crash! So it's only the mysterious random crashes that aren't causing core dumps.

Can anyone help me figure out why core dumps are not getting generated, and how I can possibly debug what is going on?


----------



## SirDice (Nov 6, 2019)

umanwizard said:


> I am running 13-CURRENT (compiled recently from source using default build settings) and recently I have been kernel panics every so often.


-CURRENT is an unsupported development version. 

Topics about unsupported FreeBSD versions


----------



## PMc (Nov 6, 2019)

There is quite a couple of reasons where no coredump is written.
One example: sending coredump to a SCSI-like drive (e.g. USB) that has been stopped will not start the drive for coredump. I also have an ATA controller that is just incompatible for coredumps, but otherwise works. Then there are some causes where the system reboots immediately - certain memory overruns in the kernel. And there are reasons where the system freezes and does nothing at all anymore.

Then, if You run GUI and really want to get some crash analysis, You need to find a way to see the console during graphics mode. That should work with a serial console, or maybe with a second monitor. (I was always too lazy to try that out, but when running CURRENT it's a must.)


----------

