Should segmentation fault handlers be written at all by a application programmer in C?

Question

If someone is a operating system programmer or writing a system level library code, it makes sense to write a segmentation fault handler. Like, for example, OS programmer would write code send a signal SIGSEGV to that application process. OR a systems library programmer might handle that signal SIGSEGV and may undo the operations caused by the library code for creating segmentation Fault. But why would an application programmer in C need to write segmentation fault handler? If he writes an handler, he has already corrupted some parts of memory. Can you give an instance, for an application programmer to handle segmentation fault and continue execution of the program?

Answer 1

AFAIK, the segmentation handler can be written at the application level, to output some debugging information (like memory dump, value of registers and other application specific information) and then exit the application.

Pls note that, since the segmentation fault might have corrupted the memory, it may or may not get all the correct information to dump.

I am not aware of any situation, where the execution of the program can be continued after a segmentation fault. May be other esteemed users of SO will be able to throw some light on this.

Answer 2

Handling SIGSEGV, etc, may allow saving state and taking corrective actions. Mr 32 (and others) are correct and you can not simply restart the main line code. Instead you can longjmp()siglongjmp(); this allows a re-start of the main line. Also, you have to be very careful to call async safe functions only. This is very tricky. However some applications are,

1. Health/saftey - to ensure a catastrophic condition doesn't happen.
2. Financial - loss of transaction data that can result in a loss of money.
3. Control system - example titration software for chemists.
4. Diagnostics - Crash conditions maybe logged to improve future software. ^{As per Jay}

Calling exit() is probably not good and _exit() would be better. The difference being atexit() calls.

See also: Cert async safe, Glibc async-safe list, Similar question, longjmp() and signals not portable, async-safe
These vary from OS to OS. Any advice will be system dependent!

---

Additional Issues

• Some libraries used by the program may catch SIGSEGV. Definitely version of the Empress Database hook it. You have to know what your libraries are using and chain to/from them.
• Stack and heap (malloc,etc) can be corrupted, including the jump_buf so your error handling maybe especially paranoid.
• There are many other alternate solutions, such as defer critical portions to another task that is much simpler.
• longjmp() called from a signal is undefined according to the C99 standard, but it will work well on most systems. siglongjmp() can be used if you are more pedantic. It would be fine for diagnostic logging, but I wouldn't use it for the other uses listed (safety, etc). Notifying a watchdog task maybe more appropriate.

Answer 3

You can catch any signal except SIGKILL, SIGCONT and SIGSTOP. Thus you can catch SIGSEGV, but if you decide then not to exit, the behavior will be unpredictable.

Answer 4

library programmer might handle that signal SIGSEGV and may 
undo the operations caused by the library code for creating segmentation

segmentation fault occurs means that threads or process will be died.

You can not undo the code caused the segmentation fault. Rather you can Re-start that component.

Answer 5

A segmentation fault is caused by the program writing to a portion of memory it is not supposed to. The application developer does not write code to handle this, they write code to avoid it. This is why you bound check when writing to memory.