Shortest code that raises a SIGSEGV

Question

Write the shortest code that raises a Segmentation Fault (SIGSEGV) in any programming language.

Answer 1

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!

Answer 2

Bash, 11      

kill -11 $$

Answer 3

Assembly (Linux, x86-64), 1 byte

RET

This code segfaults.

Answer 4

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 5

pdfTeX (51)

\def~#1{\meaning}\write0{\expandafter~\string}\bye

This is actually probably a bug, 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 6

LOLCODE, 4 bytes

OBTW

Does not work online, only in the C interpreter.

Answer 7

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 8

Forth - 3 characters

0 @

(@ is a fetch)

Answer 9

C, 18

main(){raise(11);}

Answer 10

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 11

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 12

brainfuck (2)

<.

Yes, this is implementation-dependent. SIGSEGV is the likely result from a good compiler.

Answer 13

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 14

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 15

Actually, 17 16 11 10 9 bytes

⌠[]+⌡9!*.

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 involving deeply nested itertools.chain objects, which actually uses to implement the + operator.

Answer 16

dc - 7 chars

[dx0]dx

causes a stack overflow

Answer 17

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, this results in a SIGSEGV.

Note that this is not a bug, but an expected behavior, as discussed here.

Test

./bang 
Segmentation fault (core dumped)

Try It Online !

Answer 18

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 19

Perl, 10 / 12 chars

A slightly cheatish solution is to shave one char off Joey Adams' bash trick:

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 20

Python 33

import os
os.kill(os.getpid(),11)

Sending signal 11 (SIGSEGV) in python.

Answer 21

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 22

C# - 62

System.Runtime.InteropServices.Marshal.ReadInt32(IntPtr.Zero);

Edit: 23

unsafe{int i=*(int*)0;}

Must compile with /unsafe for this one to work. For some reason I don't understand, *(int*)0=0 just throws a NullReferenceException, while this version gives the proper access violation.

Answer 23

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 24

J (6)

memf 1

memf means free memory, 1 is interpreted as a pointer.

Answer 25

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 26

Cython, 14

This often comes in handy for debugging purposes.

a=(<int*>0)[0]

Answer 27

Matlab - Yes it is possible!

In a response to a question of mine, Amro came up with this quirk:

S = struct();
S = setfield(S, {}, 'g', {}, 0)

Answer 28

JavaScript Shell, 7 bytes

clear()

Clears absolutely everything, not just the current scope which obviously causes lots of borks which result in JS blowing up and segfaulting

Answer 29

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.

Explanation

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 ♦

Answer 30

Unix PDP-11 assembly, 18 bytes binary, 7 bytes source

(this is becoming a theme with me, maybe because it's the only language I sort of know that no-one else here does.)

inc(r0)

Increments the single byte addressed by the initial value of r0 [which happens to be 05162 according to the simh debugger] as of program start.

0000000 000407 000002 000000 000000 000000 000000 000000 000000
0000020 005210 000000

And, as always, the extraneous bytes at the end can be removed with strip.

I made a few attempts to get the source shorter, but always ended up getting either a syntax error or SIGBUS.

Answer 31

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.

Answer 32

Java (OpenJDK 9), 311 227 223 bytes

import sun.misc.*;import java.lang.reflect.*;class M{public static void main(String[]args) throws Exception{Constructor<Unsafe> c=Unsafe.class.getDeclaredConstructor();c.setAccessible(true);c.newInstance().getAddress(0);}}

Try it online!

Ungolfed:

import sun.misc.Unsafe;

import java.lang.reflect.Constructor;

public class SegFault {

    public static void main(String[] args) throws Exception {
        Constructor<Unsafe> unsafeConstructor = Unsafe.class.getDeclaredConstructor();
        unsafeConstructor.setAccessible(true);
        Unsafe unsafe = unsafeConstructor.newInstance();
        System.out.println(unsafe.getAddress(0));
    }
}

Saved 84 Bytes thanks to Mistah Figg

Answer 33

x86 and x86_64 machine language, 3 bytes

0:       50                      push   %eax
1:       eb fd                   jmp    0

This pushes the value of the EAX (or RAX in long mode) register to the stack in a loop until the stack overflows.

To try this, compile and run the following C program.

const char main[]="\x50\xeb\xfd";

To try it on Windows, prepend the following to mark main as executable.

#pragma section("foo", execute)
__declspec(allocate("foo"))

Answer 34

Lua 5.3.2 PUC-RIO (the "official") interpreter - 57 bytes

local t={}t.__newindex=t local y=setmetatable({},t)y[1]=1

Note: does not work on all machines, and was fixed in Lua 5.3.3.

Answer 35

Clean, 19 12 bytes

Start=code{}

Try it online!

Every function always returns something in Clean, including Start. Because we haven't specified the type of Start, the compiler assumes (and it can only assume when you inline ABC) that it takes no arguments. Since it takes no arguments, there's nothing on either stack when the function resolves, and so the runtime tries to evaluate the first node in the spine of a graph with... Zero nodes.

Answer 36

Perl 6, 22

shell "kill -11 $*PID"

Just shelling to whatever shell you have.

Answer 37

Dyvil, 42 bytes

dyvil.reflect.ReflectUtils.UNSAFE.getInt 0

Explanation:

dyvil.reflect.ReflectUtils // qualified type name
     .UNSAFE               // accesses the static field UNSAFE in class
                           // dyvil.reflect.ReflectUtils, of type sun.misc.Unsafe
     .getInt 0             // calls the method sun.misc.Unsafe.getInt(long),
                           // which tries to read a 4-byte integer from 
                           // the memory address 0

Answer 38

Lua (luajit), 52 48 bytes

function f()c=coroutine;c.resume(c.create(f))end

An attempt to compete for the bounty that was recently set on an answer in Lua. This is a function submission (basically because I had to define a function anyway, so not including the code to run it saves bytes). Now with 4 bytes saved due to a suggestion by @ceilingcat to avoid repeating the word coroutine.

The program works by creating infinitely many coroutines, suspending each in turn to create and start the next. The most commonly used Lua interpreter, lua, thought of this case and starts causing coroutine creation to fail after a while. luajit, however, segfaults. (Valgrind reports the issue as a failure to grow the OS-defined stack; this is believable, seeing as one common coroutine implementation gives them each separate parts of the stack.)

Answer 39

Lua (LuaJIT), 47 43 bytes

f=require"ffi"f.cdef"int puts()"f.C.puts()

Uses FFI in LuaJIT to call puts() with no (valid) argument.

Answer 40

Ruby, 15 bytes

eval a='eval a'

Segfaults (Ruby 2.3 on Ubuntu xenial)

Answer 41

Befunge-98 (FBBI), 1 byte

=

Try it online! (expand the Debug section to view the segfault)

This only works in the FBBI implementation of Befunge, exploiting a bug in its string handling code. Any attempt to read a string from an empty stack will result in a null pointer dereference. You can achieve the same result with the i (Input File) and o (Output File) instructions, which also expect a string on the stack.

Note that this error wouldn't occur if the stack was simply full of zeros, which in Befunge should be semantically equivalent to an empty stack. For it to crash the stack must be genuinely empty, as is the case on startup.

Answer 42

Tcl, 60 bytes

set a a;while {[incr i]<999999999} {set a [list $a]};puts $a

Not short, but crashes with a segfault.

This builds a deeply nested list (each with only one element), and when trying to serialize it, Tcl will crash with a stack overflow.

I have reported this bug here

Answer 43

Rust, 34 bytes

fn main(){unsafe{*(0 as*mut _)=3}}

Just a null pointer assignment, nothing special here.

---

As a bonus, 45 44 bytes solution not using unsafe. Arguably a bug in a compiler.

#![no_main]#[no_mangle]pub static main:i8=0;

Main is usually a function ;).

Answer 44

x86 .COM, 2 Bytes

66 61 POPAD

x86 .COM, 5 3 Bytes

A3 FF FF

Write to the segment border

Answer 45

Haskell, 15 bytes

Causes a stackoverflow:

main=main>>main

Try it online!

Answer 46

Battlestar, 3 characters

ret

Test

 $ echo ret > main.bts
 $ bts main.bts
 (segfaults)

Answer 47

Whispers, 5 bytes

>> 1!

Try it online!

How it works

>> 1  - Call this line repeated
    ! - Prevent tail call

Answer 48

C, 20 bytes

Not the shortest, but it occurred when I was programming and I thought it was mildy interesting. However, I do believe this error is different than the original error I occured (*** stack smashing detected ***), but this is a SIGBUS (10). I was going to post this to the SIGBUS question, but it says it has been closed as a duplicate of this </overexplanation>

f(){int*u;--u[-1];}

Basically decrements invalid points. Example output:

$ gcc -o program main.c && ./program
main.c:1:1: warning: type specifier missing, defaults to 'int'
      [-Wimplicit-int]
main(){int*u;--u[-1];}
^
1 warning generated.
Bus error: 10
$ echo $?
138

Answer 49

Common Lisp (SBCL), 79 bytes.

SBCL captures pretty much every exception and signal, but we can cause an "Unhandled memory exception" which is the result of a SIGSEGV. We must tell SBCL to not consider type safety and just add a fixnum to a float, which ends up disastrous.

(defun f(x)(declare (optimize (safety 0))(fixnum x))(the fixnum (1+ x)))(f 0.0)

My SBCL image errors with:

Unhandled memory fault at #x14.
   [Condition of type SB-SYS:MEMORY-FAULT-ERROR]

Evaluating (f '(1 5)) returned a garbage object, then (gc) threw Lisp into the low-level debugger after it tried to GC that object presumably. I don't see the difference in results since it is possible to jump back into Lisp from this state, and I imagine this is 100% platform dependent behavior.

Answer 50

Nasm, 3 bytes.

Either

ret

or

nop

ret raises SIGSEGV via stack underflow, and nop raises SIGSEGV simply because there's no exit point.

Answer 51

TI-BASIC, 5 bytes

Archive A:A

Archives the variable A and then tries to get the value of A.
Throws the ERR:ARCHIVED error when used.

This is the closest thing you'd get to a segmentation fault in TI-BASIC, since archived data cannot be accessed directly.

In other words, the software has attempted to access a restricted area of memory.

---

Note: TI-BASIC is a tokenized language. Character count does not equal byte count.

Answer 52

F90 - 25 chars

REAL A(1)
n=2
A(n)=0
END

Compiled with Intel compiler 12.0 which actually refuses to compile without the intermediate n as it detects the bound error. Does this count as a segfault?:

ifort -C sigsegv.F90 
./a.out 
forrtl: severe (408): fort: (2): Subscript #1 of the array A has value 2 which is greater than the upper bound of 1