# Shortest code that raises a SIGSEGV

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

• Wow. Possibly the shortest successful question. Feb 9, 2017 at 11:42
• @MatthewRoh Out of interest, I made this SEDE query. It looks like there are a few with +10 or higher, but this is the first above +40 Nov 21, 2020 at 20:38

# 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!

• @Macmade: Actually, it is 0. static variables start as 0, and main; is static, as I declared it outside function. c-faq.com/decl/initval.html Aug 16, 2013 at 8:20
• last time i played with this thing, i figured out that there's a different reason for the segfault. First of all by calling main you jump to the location of main, not the value, another thing is main is an int, it's located in .bss, usually functions are located in .text, when the kernel loads the elf program it creates an executable page for .text and non-executable for .bss, so by calling main, you jump to a non-executable page, and execution something on a such page is a protection fault. Dec 6, 2013 at 17:55
• Yep, segfaults in C are pretty much the default :P May 24, 2014 at 23:23
• main __attribute__((section(".text#")))=0xc3; FTFY (at least it seems to return without crashing on my x86). Jul 27, 2018 at 4:57
• @jozxyqk Or shorter, const main=195;. As interesting it is that it's working, the goal of this code golfing challenge was to make the code segfault, not work :). Jul 27, 2018 at 6:48

kill -11 $$ • Signal 11 in 11 characters. Seems legit. Dec 31, 2013 at 12:39 • @nyuszika7h I was going to upvote your comment, but you have 11 upvotes right now, so I'm going to leave it at that. :P Nov 25, 2016 at 16:22 • @AlexL. other people seem to have spoiled that :( Jan 21, 2017 at 10:51 • @theonlygusti Yeah... That's too bad. :( Oh well, then I can upvote it now. Jan 21, 2017 at 14:27 • Up to 42 upvotes, no touchee! Sep 3, 2018 at 15:24 # Assembly (Linux, x86-64), 1 byte RET  This code segfaults. • As an MSDOS .com file, it runs and terminates without error. – J B Dec 26, 2011 at 19:10 • My point being: just specifying “assembly” isn't enough to make it segfault. – J B Dec 26, 2011 at 19:56 • @JB: On MS DOS, no program will ever produce a segmentation fault. That's because MS DOS runs in real mode where memory protection is nonexistent. Feb 4, 2012 at 17:25 • @celtschk IIRC NTVDM will eke out on nonexistent addresses, and those not allocated to MS-DOS. Jan 31, 2013 at 1:32 • @celtschk: You can segfault it anyway like so: mov bx, 1000h ; shr ebx, 4 ; mov eax, [ebx] -> CPU raises the underlying SEGV (AFAIK there's nobody to handle it though). Nov 20, 2016 at 17:18 # 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. • Segmentation fault: 11 on Mac Nov 2, 2015 at 1:29 • Segmentation fault (core dumped) on Linux – user45941 Nov 2, 2015 at 1:30 • @MegaMan As in take a long time to finish? No, 7**6 is only about 100K so there's no perceptible delay. Aug 14, 2016 at 2:46 • @MaxGasner Try reading the programming language again :) Aug 6, 2019 at 4:03 • Yeah, it doesn't work on 3.8.9 (or at least my build of 3.8.9) on OS X. -- at least this version is clever enough to instead give you aRecursionError Jun 23, 2021 at 18:40 # 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. # LOLCODE, 4 bytes OBTW  Does not work online, only in the C interpreter. • LOL FANCY CODE M8 8/8 KTHXBYE Nov 2, 2015 at 15:52 # 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). ## Python, 33 characters >>> import ctypes;ctypes.string_at(0) Segmentation fault  ## Python, 60 characters >>> import sys;sys.setrecursionlimit(1<<30);f=lambda f:f(f);f(f) Segmentation fault  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... # 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 ! # Forth - 3 characters 0 @  (@ is a fetch) • Shortest one so far that will work on modern systems. – Demi Mar 6, 2015 at 6:06 • Which Forth? Gforth just says "Invalid memory address" – cat Mar 5, 2016 at 1:25 # 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. • I can reproduce this on Perl 5.14 (Debian) and 5.18 (Arch Linux). sprunge.us/RKHT Jan 21, 2014 at 21:51 • Reproduced with Perl v5.20.2 (windows) Mar 11, 2016 at 13:38 • What about /(?R)/ on older Perl versions? Sep 2, 2020 at 13:37 ## brainfuck (2) <.  Yes, this is implementation-dependent. SIGSEGV is the likely result from a good compiler. • How is a compiler that segfaults on that "good"? That < should either have no effect or wrap around. Jul 4, 2014 at 17:38 • Immediately producing a runtime error on bounds violation is best because it lets the programmer find and fix the bug as fast as possible. Letting the buggy program run for a while and corrupt memory haphazardly before crashing just makes the problem harder to diagnose. Preventing the crash entirely, as you suggest, is worst; the programmer may get the program "working" and then be publicly humiliated when it crashes on standard compilers and interpreters. Oct 12, 2014 at 23:17 • Conversely, catching bounds violations before runtime is not possible in general, nor especially useful in the cases where it is possible. Producing a more descriptive runtime error would be okay, but having the operating system catch it as a segfault is great because it doesn't have any speed cost. (In case it's not clear, the compiler itself doesn't segfault--it produces executables that segfault as soon as they try to access memory out of bounds.) Oct 12, 2014 at 23:35 • Can you provide an implementation that produces this behavior and was created before this challenge was posted? If not, this answer is invalid. – user45941 Apr 25, 2016 at 20:10 • Bounds checks are implementation specific, so I'm sure there are some that would error on it. Would any SIGSEGV though? I doubt it. There are a large number of programs that depend on the array wrapping to the left though. It can be rather convenient having growable storage on both sides. Dec 15, 2016 at 20:01 ## C, 18 main(){raise(11);}  • do you need to add #include <signal.h> in the code listing? Nov 28, 2016 at 8:16 • @FlorianCastellane: in C90 and lower, for any function call done without a visible declaration, the compiler implicitly declares it as int func(). i.e. a function returning int, taking unspecified parameters. In this case raise is a function returning int, taking an int argument, so this works out (even if the compiler complains). Nov 28, 2016 at 13:26 • @Hasturkun main(){main();} Mar 9, 2020 at 1:16 ## 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. • Awwww. I was gonna post import Foreign;main=peek nullPtr::IO Int, but that's 40. Dec 25, 2020 at 20:02 ## 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  • in C isn't main; only 5 charecters Dec 26, 2011 at 10:50 • :Linker doesn't check whether main is function or not .It just pass it to the loader and return sigsegv Dec 26, 2011 at 12:24 • @FUZxxl In this case main is a zero-initialized global int variable, so what we get is a result of trying to execute some zero bytes. In x86 it'd be something like add %al,(%rax) which is a perfectly valid instruction which tries to reach memory at address stored in %rax. Chances of having a good address there are minimal. Dec 27, 2011 at 20:35 • Of course the last entry can be used for everything, you just have to supply the right compiler arguments. Which should make it the automatic winner of any code golf contest. :-) Feb 4, 2012 at 17:20 • Usually compiler flags other than ones that choose the language version to use are counted towards the total. Dec 11, 2014 at 4:32 ## 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.

• What is this 1x8 thing? Dec 15, 2016 at 10:19
• @HannesKarppila It's a short way to write "11111111". Dec 15, 2016 at 12:18
• You can replace 1x8 with $^, it's long enough in both 32 and 64 bit. Jul 28, 2021 at 8:09 # Python 33 import os os.kill(os.getpid(),11)  Sending signal 11 (SIGSEGV) in python. • Also 33 characters: from os import* and kill(getpid(),11) Jan 8, 2014 at 15:45 # 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  • Nice first post. Mar 25, 2016 at 18:03 # dc - 7 chars [dx0]dx  causes a stack overflow • Is works, but can you elaborate? Why does it behave that way? Nov 21, 2016 at 12:17 • [dx0] stores dx0 on the stack, then d duplicates the top stack element, then x pops the top stack element (dx0) and executes it. Which duplicates the top stack element, and starts executing it... the 0 needs to be there to prevent this being a tail call, so they all build up. Nov 26, 2016 at 7:58 # 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.

# 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.

# 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.

• it coerces 0 (stored as the immediate value 1) - why is 0 stored as 1? Nov 3, 2015 at 14:15
• @Skyler see edit
– Demi
Nov 4, 2015 at 19:02
• Obj.magic()0 is one char shorter :) Nov 26, 2016 at 7:53

# 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 ♦

• Figured something out! From browsing Pyth's source, I found that this code does j on 1 and 0, which tries to convert 1 into base 0. Why that segfaults, I have no idea... Dec 23, 2016 at 1:24
• See here. 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. Dec 23, 2016 at 1:30
• @Dennis IDEone Dec 23, 2016 at 1:35
• @SeeRhino The Pyth interpreter sets the recursion limit to 100,000. At least on TIO, that's enough for a segfault. Dec 23, 2016 at 1:38

## 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.

• It depends on the stack frame layout, so in some architecture it can possibly not fail. Dec 27, 2011 at 19:41
• Why not simply main;, or main(){*""=0;}? Nov 16, 2020 at 1:23
• @Sapphire_Brick main; is already given in another answer. Nov 17, 2020 at 4:08
• @saeedn Then why post it at all? This one isn't even the second to shortest! Nov 17, 2020 at 5:27
• @Sapphire_Brick At the time I was posting mine, main; wasn't posted and I didn't know it works. I was only pointing out that it is already given and no point in changing my answer. Furthermore, people here don't just post only for the shortest, sometimes a different way of solving the problem is also interesting. Nov 18, 2020 at 17:20

## Cython, 14

This often comes in handy for debugging purposes.

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


## 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.

• The int i=*(int*)0; returns a NullReferenceException for me. Dec 30, 2011 at 7:43
• You can try to access a negative location, like *(int*)-1=0 and get an access violation. Dec 30, 2011 at 7:46
• The particular exception is just what the clr wraps it in, and is insignificant. The os itself actually gives the seg fault in all these cases. Jan 20, 2012 at 17:41
• The reason why *(int*)0=0 throws an exception is likely due to optimization. Specifically, to avoid the cost of checking for null, the optimizer may remove null checks, but when a segfault occurs it may rethrow it as a proper NullReferenceException. Sep 15, 2018 at 20:55

## J (6)

memf 1


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

• Why 1 rather than 0? Is it legal to free a null pointer in J? Nov 18, 2020 at 18:35

# 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)

• Please give Matlab version -- R2015B (and 2016B also) just throws an error: Error using setfield (line 56) At least one index is required. Nov 28, 2016 at 8:24
• @FlorianCastellane Not able to try all versions now, but it has been confirmed to give a segfault in quite some versions, the latest being 2014b and the earliest 2012a. Nov 29, 2016 at 16:13

# 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.

• I'm pretty sure you have to score with the additional args
– Blue
Dec 16, 2016 at 12:36
• You have to add 14 bytes for the special flag. Dec 16, 2016 at 12:38
• @ErikGolferエリックゴルファー -nostartfiles is actually 13 bytes long :) Dec 16, 2016 at 13:34
• @CharlesPaulet I think you have to count the space too. Dec 16, 2016 at 13:37

# Rust, 34 bytes

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


Just a null pointer assignment, nothing special here.

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

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


Main is usually a function ;).