[Question]
  [
Write the shortest code that raises a [Segmentation Fault (SIGSEGV)](http://en.wikipedia.org/wiki/SIGSEGV) in any programming language.
  
[Answer]
# C, 5 characters
```
main;
```
It's a variable declaration - `int` type is implied (feature copied from B language) and `0` is default value. When executed this tries to execute a number (numbers aren't executable), and causes `SIGSEGV`.
[Try it online!](https://tio.run/##S9ZNT07@/z83MTPP@v9/AA "C (gcc) – Try It Online")
[Answer]
## Bash, 11
```
kill -11 $$
```
[Answer]
# Assembly (Linux, x86-64), 1 byte
```
RET
```
This code segfaults.
[Answer]
# Python 2, 13
```
exec'()'*7**6
```
Windows reports an error code of c00000fd (Stack Overflow) which I would assume is a subtype of segmentation fault.
Thanks to Alex A. and Mego, it is confirmed to cause segmentation faults on Mac and Linux systems as well. Python is the language of choice for portably crashing your programs.
[Answer]
# pdfTeX (51)
```
\def~#1{\meaning}\write0{\expandafter~\string}\bye
```
This is actually probably [a bug](http://groups.google.com/group/comp.text.tex/browse_thread/thread/4841c950ab64b14f#), but it is not present in the original TeX, written by Knuth: compiling the code with `tex filename.tex` instead of `pdftex filename.tex` does not produce a segfault.
[Answer]
# LOLCODE, 4 bytes
```
OBTW
```
Does not work online, only in the C interpreter.
[Answer]
## Python, 33 characters
```
>>> import ctypes;ctypes.string_at(0)
Segmentation fault
```
Source: <http://bugs.python.org/issue1215#msg143236>
## Python, 60 characters
```
>>> import sys;sys.setrecursionlimit(1<<30);f=lambda f:f(f);f(f)
Segmentation fault
```
Source: <http://svn.python.org/view/python/trunk/Lib/test/crashers/recursive_call.py?view=markup>
This is the Python version I'm testing on:
```
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
```
In general the Python interpreter is hard to crash, but the above is selective abusiveness...
[Answer]
# W32 .com executable - 0 bytes
This will seem weird, but on 32 bit Windows systems, creating and executing an empty .com file *may* cause a segfault, depending on... something. DOS just accepts it (the 8086 having no memory management, there are no meaningful segments to fault), and 64 bit Windows refuses to run it (x86-64 having no v86 mode to run a .com file in).
[Answer]
# Bash, 4 bytes
**Golfed**
```
. $0
```
Recursively include the script into itself.
**Explained**
Recursive "source" (.) operation causes a stack overflow eventually,
and as *Bash* does not integrate with [libsigsegv](https://www.gnu.org/software/libsigsegv/), this results in a SIGSEGV.
Note that this is not a bug, but an expected behavior, as discussed [here](https://lists.gnu.org/archive/html/bug-bash/2014-08/msg00100.html).
**Test**
```
./bang 
Segmentation fault (core dumped)
```
[Try It Online !](https://goo.gl/NSPme0)
[Answer]
# Forth - 3 characters
```
0 @
```
(`@` is a fetch)
[Answer]
## brainfuck (2)
```
<.
```
Yes, this is implementation-dependent. SIGSEGV is the likely result from a good compiler.
[Answer]
# Perl ( < 5.14 ), 9 chars
```
/(?{??})/
```
In 5.14 the regex engine was made reentrant so that it could not be crashed in this way, but 5.12 and earlier will segfault if you try this.
[Answer]
## C, 18
```
main(){raise(11);}
```
[Answer]
## Haskell, 31
```
foreign import ccall main::IO()
```
This produces a segfault when compiled with GHC and run. No extension flags are needed, as the Foreign Function Interface is in the Haskell 2010 standard.
[Answer]
## C - ~~11(19)~~ ~~7(15)~~ ~~6(14)~~ 1 chars, AT&T x86 assembler - 8(24) chars
C version is:
```
*(int*)0=0;
```
The whole program (not quite ISO-compliant, let's assume it's K&R C) is 19 chars long:
```
main(){*(int*)0=0;}
```
Assembler variant:
```
orl $0,0
```
The whole program is 24 chars long (just for evaluation, since it's not actually assembler):
```
main(){asm("orl $0,0");}
```
**EDIT**:
A couple of C variants. The first one uses zero-initialization of global pointer variable:
```
*p;main(){*p=0;}
```
The second one uses infinite recursion:
```
main(){main();}
```
The last variant is ~~the shortest one -~~ 7(15) characters.
**EDIT 2**:
Invented one more variant which is shorter than any of above - 6(14) chars. It assumes that literal strings are put into a read-only segment.
```
main(){*""=0;}
```
**EDIT 3**:
And my last try - 1 character long:
```
P
```
Just compile it like that:
```
cc -o segv -DP="main(){main();}" segv.c
```
[Answer]
## Perl, 10 / 12 chars
A slightly cheatish solution is to shave one char off [Joey Adams' bash trick](https://codegolf.stackexchange.com/a/4403/3191):
```
kill 11,$$
```
However, to get a real segfault in Perl, `unpack p` is the obvious solution:
```
unpack p,1x8
```
Technically, this isn't *guaranteed* to segfault, since the address 0x31313131 (or 0x3131313131313131 on 64-bit systems) just might point to valid address space by chance. But the odds are against it. Also, if perl is ever ported to platforms where pointers are longer than 64 bits, the `x8` will need to be increased.
[Answer]
# Python 33
```
import os
os.kill(os.getpid(),11)
```
Sending signal 11 (SIGSEGV) in python.
[Answer]
# F90 - 39 bytes
```
real,pointer::p(:)=>null()
p(1)=0.
end
```
Compilation:
```
gfortran segv.f90 -o segv 
```
Execution:
```
./segv 
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0  0x7FF85FCAE777
#1  0x7FF85FCAED7E
#2  0x7FF85F906D3F
#3  0x40068F in MAIN__ at segv.f90:?
Erreur de segmentation (core dumped)
```
Materials:
```
gfortran --version
GNU Fortran (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
```
[Answer]
# dc - 7 chars
```
[dx0]dx
```
causes a stack overflow
[Answer]
# PicoLisp - 4 characters
```
$ pil
: ('0)
Segmentation fault
```
This is intended behaviour. As described on their website:
> 
> If some programming languages claim to be the "Swiss Army Knife of Programming", then PicoLisp may well be called the "Scalpel of Programming": Sharp, accurate, small and lightweight, but also dangerous in the hand of the inexperienced.
> 
> 
> 
[Answer]
# [Actually](https://github.com/Mego/Seriously), ~~17 16 11 10~~ 9 bytes
```
⌠[]+⌡9!*.
```
[Try it online!](https://tio.run/##S0wuKU3Myan8//9Rz4LoWO1HPQstFbX0/v8HAA "Actually – Try It Online")
If the above doesn't crash, try increasing the number (multi-digit numbers are specified in Actually with a leading colon)
Crashes the interpreter by exploiting [a bug in python](https://bugs.python.org/issue14010) involving deeply nested `itertools.chain` objects, which actually uses to implement the `+` operator.
[Answer]
# OCaml, 13 bytes
```
Obj.magic 0 0
```
This uses the function `Obj.magic`, which unsafely coerces any two types. In this case, it coerces 0 (stored as the immediate value 1, due to the tag bit used by the GC) to a function type (stored as a pointer). Thus, it tries to dereference the address 1, and that will of course segfault.
[Answer]
# Pyth, 3 characters
```
j1Z
```
This would be the part where I explain how I came up with this answer, except I legitimately have *no clue*. If anyone could explain this for me, I'd be grateful.
[Here it is in an online interpreter.](http://pyth.tryitonline.net/#code=ajFa&debug=on%)
> 
> ## [Explanation](https://codegolf.stackexchange.com/questions/4399/shortest-code-that-returns-sigsegv/104269#comment253355_104269)
> 
> 
> `j` squares the base and calls itself recursively until the base is at least as large as the number. Since the base is **0**, that never happens. With a sufficienly high recursion limit, you get a segfault.
> 
> 
> [- **Dennis ♦**](https://codegolf.stackexchange.com/questions/4399/shortest-code-that-returns-sigsegv/104269#comment253355_104269)
> 
> 
> 
[Answer]
# Python 3.8+, 47 bytes
```
eval((lambda:0).__code__.replace(co_consts=()))
```
Not the shortest python entry by far, but this one works without any imports. And as a bonus, this bug is exploitable to get arbitrary code execution, if you're smart about it.
[Answer]
## 19 characters in C
```
main(a){*(&a-1)=1;}
```
It corrupts return address value of main function, so it gets a SIGSEGV on return of `main`.
[Answer]
## Cython, 14
This often comes in handy for debugging purposes.
```
a=(<int*>0)[0]
```
[Answer]
## C# - 62
```
System.Runtime.InteropServices.Marshal.ReadInt32(IntPtr.Zero);
```
# C# /unsafe, 23 bytes
```
unsafe{int i=*(int*)0;}
```
For some reason I don't understand, `*(int*)0=0` just throws a NullReferenceException, while this version gives the proper access violation. 
[Answer]
## J (6)
```
memf 1
```
`memf` means free memory, `1` is interpreted as a pointer.
[Answer]
# Matlab - Yes it is possible!
In a response to a [question](https://stackoverflow.com/q/16342688/983722) of mine, Amro came up with this quirk:
```
S = struct();
S = setfield(S, {}, 'g', {}, 0)
```
[Answer]
# C - 14 chars
Be sure to compile an empty file with `cc -nostartfiles c.c`
> 
> ### Explanation:
> 
> 
> What went wrong is that we treated \_start as if it were a C function, and tried to return from it. In reality, it's not a function at all. It's just a symbol in the object file which the linker uses to locate the program's entry point. When our program is invoked, it's invoked directly. If we were to look, we would see that the value on the top of the stack was the number 1, which is certainly very un-address-like. In fact, what is on the stack is our program's argc value. After this comes the elements of the argv array, including the terminating NULL element, followed by the elements of envp. And that's all. There is no return address on the stack.
> 
> 
> 
]