Notice how our previous test case, sending 5,000 SIGUSR1 signals to the defer_or_not application running with SA_NODEFER set, caused it to crash with a segmentation fault (often abbreviated as segfault). The OS sent the signal SIGSEGV (segmentation violation) to the process when it made an invalid memory reference; in other words, a bug related to a memory access. Trapping the SIGSEGV could be very valuable; we can gain information concerning how and why the application crashed (in fact, we shall do precisely this in the next chapter). 

However, think carefully: in the last test case (the 5,000 signals... one), the reason the process crashed is that its stack overflowed. Thus, the OS delivered the signal SIGSEGV; we want to trap this signal and handle it. But there's no space on the stack, so how can the signal handler function itself get invoked? This is a problem.

An interesting solution exists: we can allocate (virtual) memory space for, and set up a separate alternate stack to be used for signal handling only. How? Via the sigaltstack(2) system call. It's used for these kind of circumstances: you need to handle a SIGSEGV, but you're out of stack space. Think about our previous real-time high-volume signal-handling application: we could perhaps redesign it such that we allocate a lot more space for a separate signal stack, so that it works in practice.