Editing Segmentation fault (section)

== Handling ==

The default action for a segmentation fault or bus error is [[abnormal termination]] of the process that triggered it. A [[core file]] may be generated to aid debugging, and other platform-dependent actions may also be performed. For example, [[Linux]] systems using the grsecurity patch may log SIGSEGV signals in order to monitor for possible intrusion attempts using [[buffer overflow]]s.

On some systems, like Linux and Windows, it is possible for the program itself to handle a segmentation fault.<ref>{{Cite web|url=https://feepingcreature.github.io/handling.html|title=Cleanly recovering from Segfaults under Windows and Linux (32-bit, x86)|access-date=2020-08-23}}</ref> Depending on the architecture and operating system, the running program can not only handle the event but may extract some information about its state like getting a [[stack trace]], [[processor register]] values, the line of the source code when it was triggered, memory address that was invalidly accessed<ref>{{Cite web|url=https://github.com/vmarkovtsev/DeathHandler|title=Implementation of the SIGSEGV/SIGABRT handler which prints the debug stack trace.|website=[[GitHub]]|access-date=2020-08-23}}</ref> and whether the action was a read or a write.<ref>{{Cite web|url=https://stackoverflow.com/questions/17671869/how-to-identify-read-or-write-operations-of-page-fault-when-using-sigaction-hand|title=How to identify read or write operations of page fault when using sigaction handler on SIGSEGV?(LINUX)|access-date=2020-08-23}}</ref>

Although a segmentation fault generally means that the program has a bug that needs fixing, it is also possible to intentionally cause such failure for the purposes of testing, debugging and also to emulate platforms where direct access to memory is needed. On the latter case, the system must be able to allow the program to run even after the fault occurs. In this case, when the system allows, it is possible to handle the event and increment the processor program counter to "jump" over the failing instruction to continue the execution.<ref>{{Cite web|url=https://devarea.com/linux-writing-fault-handlers/|title=LINUX – WRITING FAULT HANDLERS|date=12 November 2017 |access-date=2020-08-23}}</ref>