Issue
As far as I know, the only ways that the Linux kernel will clean up a process entry is if that process performs an exit(2) syscall or it fails to handle a fatal signal (like SIGSEGV, SIGABRT, SIGTERM, SIGKILL, etc). I know that SIGKILL cannot be handled and so doesn't even actually get "delivered" to the process.. that's somewhat along the lines of what I'm thinking here.
Assuming the kernel itself stays intact and valid (not interested in hardware failure/device shutdown/panic/etc), are there any other ways a process can be destroyed?
Goal is to ensure coverage of a crash reporting framework - I'm pretty sure that fatal signals + exit(2) constitute the only ways I can die, but I'd like to make sure.
Solution
Yes, I believe you're correct that those are the only possibilities.
You can confirm this from the documentation of wait(2). There are two related macros, WIFEXITED() and WIFSIGNALED() that can be used to determine why wait returned the given process. There are no other possibilities (I'm not counting WIFSTOPPED(), since it's used for detecting suspended processes, not processes that have terminated).
Actually, exit(3) is not a system call, it's a C library function. The system call is _exit(2). exit(3) performs some C cleanup (e.g. flushing stdio buffers and calling atexit() functions) and then calls _exit(2) to actually exit the process.
Answered By - Barmar
