Why wouldn't it be able to? A segfault is just a signal like any other.

I thought it couldn't be caught, but I checked the docs, and it seems it can.

Hmm, maybe I should put that in all my programs - then I won't ever have bugs from segfaults.

:)

Back in my student days long ago, a friend of mine who was working on a very difficult assignment hatched a plan to include a SIGSEGV handler that would print "NFS server not responding, still trying..." for use on the day when we had to demo the results to the TAs. The NFS system was pretty flaky and his hope was that the TA would move on to the next demo and get back to him, giving him time to fix whatever problem was happening. Not sure if he actually put it in though.

Back in my student days for DOS-based labs we just did

  char foo[640*1024];
  int main(int argc, char ** argv) { return 0; }

When ran, it made the OS say "Out of memory" and then it was lab assistant's headache to unload all that resident stuff that was sitting there and eating good 20-30% of available RAM. They typically opposed to doing that, so the TAs assumed the program actually worked. The end :)

I must be the only moron who used to be eager for others to see his programs. No teacher ever looked at it long enough to appreciate it though; I quickly established a reputation as a computer show off and the teachers were dismissive of me, spending more time with kid who actually had problems.

>> I quickly established a reputation as a computer show off

Hmm ... :)

Because the state of a process is undefined after a seg fault.

"undefined" doesn't mean it has no state. it does have some state. it's just that this state can't be predicted. it can still be recorded and used in debugging backwards.

2 comments about that: First, it must be well defined in order for the operating system to be able to do something about the process. It may not be consistent, predictable to userspace, or runnable, but it must be something possibly sensible. Therefore, it doesn't matter, the debugger can still inspect it, and the programmer can make sense of this state.

Second, the debugger generally catches the signal before it gets handled.