Editing Segmentation fault (section)

== Examples ==
[[File:Card reader segfault.jpg|thumb|right|Segmentation fault on an [[EMV]] keypad]]

=== Writing to read-only memory ===
Writing to read-only memory raises a segmentation fault. At the level of code errors, this occurs when the program writes to part of its own [[code segment]] or the read-only portion of the [[data segment]], as these are loaded by the OS into read-only memory.

Here is an example of [[ANSI C]] code that will generally cause a segmentation fault on platforms with memory protection. It attempts to modify a [[string literal]], which is undefined behavior according to the ANSI C standard. Most [[compiler]]s will not catch this at compile time, and instead compile this to executable code that will crash:

<syntaxhighlight lang=c>
int main(void)
{
    char *s = "hello world";
    *s = 'H';
}
</syntaxhighlight>

When the program containing this code is compiled, the string "hello world" is placed in the [[rodata]] section of the program [[executable file]]: the read-only section of the [[data segment]]. When loaded, the operating system places it with other strings and [[constant (programming)|constant]] data in a read-only segment of memory. When executed, a variable, ''s'', is set to point to the string's location, and an attempt is made to write an ''H'' character through the variable into the memory, causing a segmentation fault. Compiling such a program with a compiler that does not check for the assignment of read-only locations at compile time, and running it on a Unix-like operating system produces the following [[runtime error]]:

<syntaxhighlight lang="console">
$ gcc segfault.c -g -o segfault
$ ./segfault
Segmentation fault
</syntaxhighlight>

[[Backtrace]] of the core file from [[GDB]]:

<syntaxhighlight lang=c>
Program received signal SIGSEGV, Segmentation fault.
0x1c0005c2 in main () at segfault.c:6
6               *s = 'H';
</syntaxhighlight>

This code can be corrected by using an array instead of a character pointer, as this allocates memory on stack and initializes it to the value of the string literal:
<syntaxhighlight lang=c>
char s[] = "hello world";
s[0] = 'H';  // equivalently, *s = 'H';
</syntaxhighlight>
Even though string literals should not be modified (this has undefined behavior in the C standard), in C they are of <code>static char []</code> type,<ref>{{cite book|title=ISO/IEC 9899:1990 - Programming languages -- C|section=6.1.4 String literals}}</ref><ref>{{cite book|title=ISO/IEC 9899:1999 - Programming languages -- C|section=6.4.5 String literals}}</ref><ref>{{cite book|title=ISO/IEC 9899:2011 - Programming languages -- C|section=6.4.5 String literals|url=http://www.iso-9899.info/n1570.html#6.4.5p6}}</ref> so there is no implicit conversion in the original code (which points a <code>char *</code> at that array), while in C++ they are of <code>static const char []</code> type, and thus there is an implicit conversion, so compilers will generally catch this particular error.

=== Null pointer dereference ===
In C and C-like languages, [[null pointer]]s are used to mean "pointer to no object" and as an error indicator, and [[dereferencing]] a null pointer (a read or write through a null pointer) is a very common program error. The C standard does not say that the null pointer is the same as the pointer to [[memory address]]&nbsp;0, though that may be the case in practice. Most operating systems map the null pointer's address such that accessing it causes a segmentation fault. This behavior is not guaranteed by the C standard. Dereferencing a null pointer is [[undefined behavior]] in C, and a conforming implementation is allowed to assume that any pointer that is dereferenced is not null.

<syntaxhighlight lang=c>
int *ptr = NULL;
printf("%d", *ptr);
</syntaxhighlight>

This sample code creates a [[null pointer]], and then tries to access its value (read the value). Doing so causes a segmentation fault at runtime on many operating systems.

Dereferencing a null pointer and then assigning to it (writing a value to a non-existent target) also usually causes a segmentation fault:
<syntaxhighlight lang=c>
int *ptr = NULL;
*ptr = 1;
</syntaxhighlight>

The following code includes a null pointer dereference, but when compiled will often not result in a segmentation fault, as the value is unused and thus the dereference will often be optimized away by [[dead code elimination]]:
<syntaxhighlight lang=c>
int *ptr = NULL;
*ptr;
</syntaxhighlight>

=== Buffer overflow ===
{{Main|Buffer overflow}}

The following code accesses the character array <code>s</code> beyond its upper boundary. Depending on the compiler and the processor, this may result in a segmentation fault.
<syntaxhighlight lang=c>
char s[] = "hello world";
char c = s[20];
</syntaxhighlight>
=== Stack overflow ===
{{Main|Stack overflow}}
Another example is [[recursion]] without a base case:

<syntaxhighlight lang="c">
int main(void)
{
    return main();
}
</syntaxhighlight>

which causes the [[stack overflow|stack to overflow]] which results in a segmentation fault.<ref>{{Cite web |title=What is the difference between a segmentation fault and a stack overflow? |url=https://stackoverflow.com/questions/2685413/what-is-the-difference-between-a-segmentation-fault-and-a-stack-overflow/2685434#2685434 |access-date=2023-11-11 |website=Stack Overflow |language=en}}</ref>  Infinite recursion may not necessarily result in a stack overflow depending on the language, optimizations performed by the compiler and the exact structure of a code.  In this case, the behavior of unreachable code (the return statement) is undefined, so the compiler can eliminate it and use a [[tail call]] optimization that might result in no stack usage.  Other optimizations could include translating the recursion into iteration, which given the structure of the example function would result in the program running forever, while probably not overflowing its stack.