The shell wrote Segmentation fault, and the kernel wrote the details: which process, where it reached and in which code.
Segmentation fault (a segfault) means the program accessed memory that does not belong to it. The kernel ends it with the SIGSEGV signal, number 11, so the status is 128 + 11 = 139. The buffer gets this line:
thumbgen[1046] is the name and PID of the process, segfault at 0 is the address it accessed (0 is a null pointer, a common bug in code), and in libc.so.6 is the library whose code it happened in. Developers fix such a bug, while for an administrator the line tells which program crashed, when, and whether the crash repeats.
Every kernel line has an importance level — from emerg to debug. An ext4 error is written at crit, a kill by the OOM killer at err, and a segfault at info: the kernel treats a single program's crash as that program's own business. dmesg -l selects lines by level.
You look for crashed programs with sudo dmesg -l err,crit. Will the line thumbgen[…]: segfault at 0 … be in the output?
-
-Tchanges how the time at the start of the line looks, not the selection.-lselects, and segfault has the level info. -
The kernel writes a single program's crash with the level info.
sudo dmesg -l info | grep segfaultfinds the line, or justsudo dmesg | grep segfault.
The segfault line has the level info, and -l err,crit drops it. Search for crashes by the word: sudo dmesg -T | grep segfault.
Key points
-
segfault at … in …— a process touched memory not its own; the kernel ended it with SIGSEGV, status 139. - The segfault line holds the name and PID of the process, the address it accessed and the library where it happened.
-
A segfault has the level info:
dmesg -l err,critdoes not show it.