1*15858da5SNam Caocoredump selftest 2*15858da5SNam Cao================= 3*15858da5SNam Cao 4*15858da5SNam CaoBackground context 5*15858da5SNam Cao------------------ 6*15858da5SNam Cao 7*15858da5SNam Cao`coredump` is a feature which dumps a process's memory space when the process terminates 8*15858da5SNam Caounexpectedly (e.g. due to segmentation fault), which can be useful for debugging. By default, 9*15858da5SNam Cao`coredump` dumps the memory to the file named `core`, but this behavior can be changed by writing a 10*15858da5SNam Caodifferent file name to `/proc/sys/kernel/core_pattern`. Furthermore, `coredump` can be piped to a 11*15858da5SNam Caouser-space program by writing the pipe symbol (`|`) followed by the command to be executed to 12*15858da5SNam Cao`/proc/sys/kernel/core_pattern`. For the full description, see `man 5 core`. 13*15858da5SNam Cao 14*15858da5SNam CaoThe piped user program may be interested in reading the stack pointers of the crashed process. The 15*15858da5SNam Caocrashed process's stack pointers can be read from `procfs`: it is the `kstkesp` field in 16*15858da5SNam Cao`/proc/$PID/stat`. See `man 5 proc` for all the details. 17*15858da5SNam Cao 18*15858da5SNam CaoThe problem 19*15858da5SNam Cao----------- 20*15858da5SNam CaoWhile a thread is active, the stack pointer is unsafe to read and therefore the `kstkesp` field 21*15858da5SNam Caoreads zero. But when the thread is dead (e.g. during a coredump), this field should have valid 22*15858da5SNam Caovalue. 23*15858da5SNam Cao 24*15858da5SNam CaoHowever, this was broken in the past and `kstkesp` was zero even during coredump: 25*15858da5SNam Cao 26*15858da5SNam Cao* commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in /proc/PID/stat") changed kstkesp to 27*15858da5SNam Cao always be zero 28*15858da5SNam Cao 29*15858da5SNam Cao* commit fd7d56270b52 ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping") fixed it for the 30*15858da5SNam Cao coredumping thread. However, other threads in a coredumping process still had the problem. 31*15858da5SNam Cao 32*15858da5SNam Cao* commit cb8f381f1613 ("fs/proc/array.c: allow reporting eip/esp for all coredumping threads") fixed 33*15858da5SNam Cao for all threads in a coredumping process. 34*15858da5SNam Cao 35*15858da5SNam Cao* commit 92307383082d ("coredump: Don't perform any cleanups before dumping core") broke it again 36*15858da5SNam Cao for the other threads in a coredumping process. 37*15858da5SNam Cao 38*15858da5SNam CaoThe problem has been fixed now, but considering the history, it may appear again in the future. 39*15858da5SNam Cao 40*15858da5SNam CaoThe goal of this test 41*15858da5SNam Cao--------------------- 42*15858da5SNam CaoThis test detects problem with reading `kstkesp` during coredump by doing the following: 43*15858da5SNam Cao 44*15858da5SNam Cao#. Tell the kernel to execute the "stackdump" script when a coredump happens. This script 45*15858da5SNam Cao reads the stack pointers of all threads of crashed processes. 46*15858da5SNam Cao 47*15858da5SNam Cao#. Spawn a child process who creates some threads and then crashes. 48*15858da5SNam Cao 49*15858da5SNam Cao#. Read the output from the "stackdump" script, and make sure all stack pointer values are 50*15858da5SNam Cao non-zero. 51