Editing Segmentation fault (section)

{{short description|Computer fault caused by access to restricted memory}}
{{redirect|Segfault|the website|Segfault (website)}}
{{More citations needed|date=November 2011}}
In [[computing]], a '''segmentation fault''' (often shortened to '''segfault''') or '''access violation''' is a [[Interrupt|failure condition]] raised by hardware with [[memory protection]], notifying an [[operating system]] (OS) the software has attempted to access a restricted area of memory (a memory access violation). On standard [[x86]] computers, this is a form of [[general protection fault]]. The operating system [[kernel (operating system)|kernel]] will, in response, usually perform some corrective action, generally passing the fault on to the offending [[Process (computing)|process]] by sending the process a [[signal (IPC)|signal]]. Processes can in some cases install a custom signal handler, allowing them to recover on their own,<ref name="Peter Van der Linden">''Expert C programming: deep C secrets'' By Peter Van der Linden, page 188</ref> but otherwise the OS default signal handler is used, generally causing [[abnormal termination]] of the process (a program [[Crash (computing)|crash]]), and sometimes a [[core dump]].

Segmentation faults are a common class of error in programs written in languages like [[C (programming language)|C]] that provide low-level memory access and few to no safety checks. They arise primarily due to errors in use of [[Pointer (computer programming)|pointer]]s for [[virtual memory]] addressing, particularly illegal access. Another type of memory access error is a [[bus error]], which also has various causes, but is today much rarer; these occur primarily due to incorrect ''physical'' memory addressing, or due to misaligned memory access – these are memory references that the hardware ''cannot'' address, rather than references that a process is not ''allowed'' to address.

Many programming languages have mechanisms designed to avoid segmentation faults and improve memory safety. For example, [[Rust (programming language)|Rust]] employs an ownership-based<ref>{{cite web| url = https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html| title = The Rust Programming Language - Ownership}}</ref> model to ensure memory safety.<ref>{{cite web| url = http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html| title = Fearless Concurrency with Rust - The Rust Programming Language Blog}}</ref> Other languages, such as [[Lisp (programming language)|Lisp]] and [[Java (programming language)|Java]], employ [[Garbage collection (computer science)|garbage collection]],<ref>{{Cite journal|url=http://www-formal.stanford.edu/jmc/recursive.html|title=Recursive functions of symbolic expressions and their computation by machine, Part I|last=McCarthy|first=John|author-link=John McCarthy (computer scientist)|date=April 1960|journal=[[Communications of the ACM]]|volume=4|issue=3|pages=184–195|doi=10.1145/367177.367199|s2cid=1489409|access-date=2018-09-22|doi-access=free}}</ref> which avoids certain classes of memory errors that could lead to segmentation faults.<ref>{{cite conference|last1=Dhurjati|first1=Dinakar|last2=Kowshik|first2=Sumant|last3=Adve|first3=Vikram|last4=Lattner|first4=Chris|book-title=Proceedings of the 2003 ACM SIGPLAN conference on Language, compiler, and tool for embedded systems |title=Memory safety without runtime checks or garbage collection |date=1 January 2003|volume=38|issue=7|pages=69–80|doi=10.1145/780732.780743|url=http://llvm.org/pubs/2003-05-05-LCTES03-CodeSafety.pdf|access-date=2018-09-22|publisher=ACM|language=en|isbn=1581136471|s2cid=1459540}}</ref>