Bash, 11      

kill -11 $$ 

Assembly (Linux, x86-64), 1 byte

RET 

This code segfaults.

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.

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.

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 

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

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)

brainfuck (2)

<. 

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

C, 18

main(){raise(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.

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.

Python 33

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

Sending signal 11 (SIGSEGV) in python.

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.

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 

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 

dc - 7 chars

[dx0]dx 

causes a stack overflow

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 ♦

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.

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.

Squire commit 93d3bf1, 6 bytes

" "*-1 

A quite intriguing blunder.

My initial attempt was to allocateth \$\text{II}^\text{LXIV}-\text{I}\$ bytes of memory, but alas, Squire thwarteth me by limiting string lengths to \$\text{XXXII}\$-bit integers, and even my peasant computer with a mere \$\text{VIII}\$ gigabytes of RAM was impervious to said attacks, but lo! Even if malloc rewardeth null, Squire containeth a defense stronger than steel:

void *xmalloc(size_t length) { void *ptr = malloc(length); if (ptr == NULL) { fprintf(stderr, "error allocating %zu bytes of memory\n", length); // Alas, thwarted again with SIGABRT! abort(); } return ptr; } 

Instead, I ventured into value.c and spied this:

 case SQ_TSTRING: { sq_number amnt = sq_value_to_number(rhs); struct sq_string *result = sq_string_alloc(AS_STRING(lhs)->length * amnt + 1); // ... } 

As with most strings in C, Squire terminateth all strings with \N, so Sampersand addeth \$I\$ whilst calculating the length.

Intriguingly, \$\text{I} \times -{\text{I}} + \text{I} == \text{N}\$. Therefore, this rewardeth &sq_string_empty.

struct sq_string *sq_string_alloc(unsigned length) { if (length == 0) return &sq_string_empty; // ... } 

To be more swift, Squire containeth some "static" strings for common values like "false" or "".

struct sq_string { char *ptr; int refcount; unsigned length; bool borrowed; }; struct sq_string sq_string_empty = { .ptr = "", .length = 0, .refcount = -1, .borrowed = false, }; 

Curiously, we have a string literal treateth as char *, which, despite its mutable appearances, is actually a member of the evil .rodata clan. These sneaky impostors are indistinguishable from normal strings, unless one encanteth -Wwrite-strings.

Returning to value.c, the next line triggers the .rodata impostor:

 // Lo! Sampersand hath summoned nasal demons! *result->ptr = '\0'; 

In order to make thine computer repent from nasal demons, thy great and powerful Linux exorcises Squire with a SIGSEGV.

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.

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.

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.

Phooey, Interpreter Bug, 2 bytes

<? 

Try it online!

This interpreter is so buggy it is beautiful. I can cause a bad free() with one byte of code in two ways. But that, unfortunately, is a SIGABRT. 😂

A quick check of the source code will tell you that the interpreter does not support wrapping. However, the bug isn't "lul I read backwards and it crashes", it is a little more in depth.

The Phooey code translates to these function calls:

< tape.left(1) // move left one cell ? debug() // print debug info 

So let's step through it:

First, we call tape.left(1).

 void left(int64_t amount) { right(-amount); } 

This turns into tape.right(-1):

 void right(int64_t amount = -1) { pointer += -1; 

Adding -1 to pointer results it being -1, since the initial value was zero.

However, let's double check what type pointer is:

 size_t pointer = 0; size_t furthest = 0; 

pointer is a size_t, which is an unsigned type, meaning that this -1 turns into a REALLY big number. Specifically, SIZE_MAX, the largest object size C++ is allowed to handle.

 if(pointer > furthest) furthest = pointer; 

We assign pointer to furthest, because SIZE_MAX > 0.

Now, we call debug():

void Phooey::debug() { std::cout << "Tape: " << tape << std::endl; } 

And this calls the operator overload function for std::ostream << Tape, and here is our bug:

std::ostream& operator<<(std::ostream& stream, Tape& tape) { for(size_t i = 0; i <= tape.furthest; i++) { stream << tape[i]; } } 

Let's substitute tape.furthest, if the bug wasn't clear enough:

 for(size_t i = 0; i <= SIZE_MAX; i++) { stream << tape[i]; } 

This loop will keep reading data from the tape pointer and printing it, until it segfaults. It is actually an infinite loop otherwise: Since tape.furthest is SIZE_MAX, it will always be true, as SIZE_MAX + 1 == 0.

How ironic that the bug occurs in the debug() function.

A simple way to fix this would be to add wrapping support, making sure that the pointer is always in range. As a matter of fact, almost every bug in this program can be fixed with range checks.

Bonus!

debug() is the buggiest function in this program. It segfaults even without putting any ?s in your code!

<3-509 

Try it online!

You may be saying, "How are you calling debug() without ??

And the answer is: ROP. 😂

Specifically, on this exact build of Phooey, the tape is stored on the stack, and cells[-3] contains the return address from call Phooey::run(), 0x403957.

509 bytes before that is just after Phooey::debug() sets up its stack frame. (If I set the pointer to the start of the function, it crashes too early to be interesting since the stack is unaligned). That is why I subtract 509.

It segfaults because it is definitely NOT called how the code expects it to be, and rdi doesn't have the this pointer, so it crashes.

This is OBVIOUSLY going to be dependent on the system and binary itself.

Python, 53 characters

class A:__lt__=lambda s,o:o.clear()or s vars(A)>A()<0 

This is a bit longer than some other solutions, but unlike some other solutions it

1. works in modern python versions (tested in 3.7.17, 3.8.17, 3.9.17, 3.10.12, 3.11.8 and 3.12.2)
2. doesn't look like it does anything dangerous/suspicious/illegal at first glance
3. showcases an actual interpreter crash rather than just explicitly dereferencing null/execing invalid code/etc

Btw, don't report this upstream, this issue is already known and closed as "wontfix" in CPython: https://github.com/python/cpython/issues/88004

Explanation:

The important part is essentially

class A: def __lt__(self, other): other.clear() AnyClass.__dict__ > A() 

AnyClass can be any class (A in the short version) and vars(A) is a shorthand for A.__dict__.

The issue here is that the class __dict__ property is supposed to be of type mappingproxy that is implemented as thin wrapper around regular dicts. This special type is supposed to make this dictionary immutable/read-only:

AnyClass.__dict__["foo"] = 0 # TypeError: 'mappingproxy' object does not support item assignment del AnyClass.__dict__["foo"] # TypeError: 'mappingproxy' object does not support item deletion AnyClass.__dict__.clear() # AttributeError: 'mappingproxy' object has no attribute 'clear' 

However, it's possible to circumvent this protection using python's data model. Specifically, mappingproxy doesn't reimplement all of the required methods itself, but instead just delegates to the underlying dict implementation.

So, when we do AnyClass.__dict__ > A() the following happens:

0. m = AnyClass.__dict__ is of type mappingproxy

   a = A() is of type A

1. we try to execute m > a or m.__gt__(a)

   mappingproxy doesn't implement __gt__, so it delegates this call to dict

   this essentially does something similar to

   # except this isn't a real property so it isn't accessible from pure python d = m.__internal_reference_to_underlying_dict return d.__gt__(a) 

   where d is the actual underlying storage of type dict, not the safe/immutable/read-only mappingproxy wrapper

2. we try to execute d.__gt__(a)

   dict does implement __gt__, but it doesn't know what to do with our custom type A, so it returns the special NotImplemented value

   python's data model says that when x.__gt__(y) (x > y) returns NotImplemented, you should try the swapped version y.__lt__(x) (y < x) before failing

3. we try to execute a.__lt__(d)

   our custom class A does have an implementation for __lt__ that calls clear() on the "other" object, in this case - d

So with this, we were able to call clear() on the underlying storage for the class __dict__ that was supposed to be made immutable by exposing it through a mappingproxy. This breaks some core assumptions that python heavily relies on. After that, it's pretty easy to cause a SEGFAULT by attempting to interact with an instance of AnyClass (or A in the minified version).

The use of __lt__ and > here is not mandatory, this also works with any other paired binary operator (eq/ne, add/radd, sub/rsub, mul/rmul, etc).

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 it online!, 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")) 

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.