# What is SIGILL?

SIGILL is the signal for an illegal instruction at the processor, which happens very rarely. The default action after receiving SIGILL is terminating the program and writing a core dump. The signal ID of SIGILL is 4. You encounter SIGILL very rarely, and I have absolutely no idea how to generate it in your code except via sudo kill -s 4 <pid>.

# Rules

You will have root in your programs, but if you don't want to for any reasons, you may also use a normal user. I'm on a Linux computer with German locale and I do not know the English text which is displayed after catching SIGILL, but I think it's something like 'Illegal instruction'. The shortest program which throws SIGILL wins.

• You might want to clarify whether the instruction has to be generated by the kernel or not. In particular, do you want to allow the program just generating it directly using the libc call raise(SIGILL)? – user62131 Nov 20 '16 at 9:43
• It really does say Illegal instruction (core dumped). – Erik the Outgolfer Nov 20 '16 at 10:04
• @ais523 Everything is allowed. – Mega Man Nov 20 '16 at 10:56
• For any hardware that can raise SIGILL, the answer will be the same as the instruction length. Just put an illegal instruction somewhere and try to execute it. The only interesting thing will be the convoluted toolchain involved. – OrangeDog Nov 21 '16 at 17:11
• *people posting old programs they had that didn't work* – RudolfJelin Nov 23 '16 at 16:04

# PDP-11 Assembler (UNIX Sixth Edition), 1 byte

9


Instruction 9 is not a valid instruction on the PDP-11 (in octal, it would be 000011, which does not appear on the list of instructions (PDF)). The PDP-11 assembler that ships with UNIX Sixth Edition apparently echoes everything it doesn't understand into the file directly; in this case, 9 is a number, so it generates a literal instruction 9. It also has the odd property (unusual in assembly languages nowadays) that files start running from the start, so we don't need any declarations to make the program work.

You can test out the program using this emulator, although you'll have to fight with it somewhat to input the program.

Here's how things end up once you've figured out how to use the filesystem, the editor, the terminal, and similar things that you thought you already knew how to use:

% a.out
Illegal instruction -- Core dumped


I've confirmed with the documentation that this is a genuine SIGILL signal (and it even had the same signal number, 4, all the way back then!)

• It had the same signal number because POSIX and UNIX and the SUS are closely related :) – cat Nov 20 '16 at 13:57
• Almost all of the signal numbers in V6 still have the same meanings today; the mnemonics have actually been less stable than the numbers. Compare minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/param.h with github.com/freebsd/freebsd/blob/master/sys/sys/signal.h — identical semantics for 1 through 13, but only 1, 2, and 13 have exactly the same names. (SIGALRM/14 and SIGTERM/15 were only added in V7.) (The System V lineage has a couple of changes, notably moving SIGBUS from 10 to 7 (replacing the useless SIGEMT) and SIGSYS above 15, to make room for SIGUSR1 and SIGUSR2.) – zwol Nov 20 '16 at 19:35
• @cat POSIX and SUS don't actually specify the values of signals - they do specify the meaning of some numbers when passed as arguments to the kill command, but SIGILL is not included. – Random832 Nov 20 '16 at 23:16
• a.out has multiple bytes in it, indeed (the 9 instruction compiles to two bytes, and the assembler also adds a header and footer to make the program executable). That's why I wrote the program in assembly language, not in machine code. The assembly language program has only one byte in, and compiles to a program with more bytes in; this is a code-golf problem (minimize the size of the source), not a sizecoding problem (minimize the size of the executable), so it's the 1-byte size of the source that matters. – user62131 Nov 23 '16 at 2:39
• Very clever abuse of an old but awesome system. – Mast Nov 23 '16 at 11:45

# C (x86_64, tcc), 7 bytes

main=6;


Try it online!

### How it works

The generated assembly looks like this.

    .globl  main
main:
.long 6


Note that TCC doesn't place the defined "function" in a data segment.

After compilation, _start will point to main as usual. When the resulting program is executed, it expects code in main and finds the little-endian(!) 32-bit integer 6, which is encoded as 0x06 0x00 0x00 0x00. The first byte – 0x06 – is an invalid opcode, so the program terminates with SIGILL.

# C (x86_64, gcc), 13 bytes

const main=6;


Try it online!

### How it works

Without the const modifier, the generated assembly looks like this.

    .globl  main
.data
main:
.long   6
.section    .note.GNU-stack,"",@progbits


GCC's linker treats the last line as a hint that the generated object does not require an executable stack. Since main is explicitly placed in a data section, the opcode it contains isn't executable, so the program terminates will SIGSEGV (segmentation fault).

Removing either the second or the last line will make the generated executable work as intended. The last line could be ignored with the compiler flag -zexecstack (Try it online!), but this costs 12 bytes.

A shorter alternative is to declare main with the const modifier, resulting in the following assembly.

        .globl  main
.section    .rodata
main:
.long   6
.section    .note.GNU-stack,"",@progbits


This works without any compiler flags. Note that main=6; would write the defined "function" in data, but the const modifier makes GCC write it in rodata instead, which (at least on my platform) is allowed to contain code.

• Love the complete avoidance of even using a function :) How does this work in C terms, though? Does the compiler see that main is a 6 and try to call it (which I guess would make it give up and try the instruction)? – Mia yun Ruse Nov 20 '16 at 16:15
• @JackDobson it's undefined behavior, so it doesn't work in terms of C; you're at the compiler's mercy. Clang even has a warning for this for some reason: "variable named 'main' with external linkage has undefined behavior". – Bobby Sacamano Nov 20 '16 at 16:32
• GCC will complain about main not being a function but only if you turn on the warnings (either -Wall or -pedantic will do it). – zwol Nov 20 '16 at 19:40
• I think it's pretty standard for executables for Unix-like systems to have text/data/bss segments. The linker places the .rodata section inside the text segment of the executable, and I expect this will be the case on pretty much any platform. (The kernel's program-loader only cares about segments, not sections). – Peter Cordes Nov 21 '16 at 4:31
• Also note that 06 is only an invalid instruction in x86-64. In 32-bit mode, it's PUSH ES, so this answer only works with compilers that default to -m64. See ref.x86asm.net/coder.html#x06. The only byte sequence that's guaranteed to decode as an illegal instruction on all future x86 CPUs is the 2 byte UD2: 0F 0B. Anything else could be some future prefix or instruction-encoding. Still, upvoted for a cool way to get a C compiler to stick a main label on some bytes! – Peter Cordes Nov 21 '16 at 4:35

# Swift, 5 bytes

[][0]


Access index 0 of an empty array. This calls fatalError(), which prints an error message and crashes with a SIGILL. You can try it here.

• This is one of the trickier ones ;) – Mega Man Nov 22 '16 at 18:22
• ...why on earth does it crash with a SIGILL? Who thought that was an appropriate signal? Bloody hipsters :D – Muzer Nov 23 '16 at 14:01
• @Asu No; fatalError() intentionally crashes by running ud2. Why they chose to do that I do not know, but maybe they thought the error message "Illegal instruction" made sense because the program did something illegal. – NobodyNada - Reinstate Monica Nov 23 '16 at 18:15
• Brilliant. I would bet this is also the shortest Swift code to cause a crash. – JAL Nov 23 '16 at 18:19
• @JAL Yeah; I can't think of anything shorter. I tried nil!, but the compiler couldn't infer the result type. (Also, hi JAL!) – NobodyNada - Reinstate Monica Nov 23 '16 at 18:22

# GNU C, 25 bytes

main(){__builtin_trap();}


GNU C (a specific dialect of C with extensions) contains an instruction to crash the program intentionally. The exact implementation varies from version to version, but often the developers make an attempt to implement the crash as cheaply as possible, which normally involves the use of an illegal instruction.

The specific version I used to test is gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0; however, this program causes a SIGILL on a fairly wide range of platfoms, and thus is fairly portable. Additionally, it does it via actually executing an illegal instruction. Here's the assembly code that the above compiles into with default optimization settings:

main:
pushq %rbp
movq %rsp, %rbp
ud2


ud2 is an instruction that Intel guarantees will always remain undefined.

• −6: main(){asm("ud2");} – wchargin Nov 20 '16 at 16:06
• Also, I don't know how we count bytes for raw assembly, but 00 00 0f 0b is the machine language for ud2 – wchargin Nov 20 '16 at 16:08
• @wchargin: that's an x86 + GNU C answer. This one is portable to all GNU systems. Also note that UD2 is only 2 bytes. IDK where you got those 00 bytes; they're not part of the machine code for UD2. BTW, as I commented on Dennis's answer, there are one-byte illegal instructions in x86-64 for now, but they're not guaranteed to stay that way. – Peter Cordes Nov 21 '16 at 4:43
• @wchargin: We count bytes for machine-code functions / programs like you'd expect. See some of my answers, like Adler32 in 32 bytes of x86-64 machine code, or GCD in 8 bytes of x86-32 machine code. – Peter Cordes Nov 21 '16 at 4:44
• @Ruslan: They aren't; 00 00 decodes the same in x86-64 (as add [rax], al). 00 00 0f 0b would usually SIGSEGV before SIGILL, unless you happened to have a writeable pointer in rax. – Peter Cordes Nov 24 '16 at 9:17

# C (x86_64), 11, 30, 34, or 34+15 = 49 bytes

main[]="/";
c=6;main(){((void(*)())&c)();}
main(){int c=6;((void(*)())&c)();}


I've submitted a couple of solutions that use library functions to throw SIGILL via various means, but arguably that's cheating, in that the library function solves the problem. Here's a range of solutions that use no library functions, and make varying assumptions about where the operating system is willing to let you execute non-executable code. (The constants here are chosen for x86_64, but you could change them to get working solutions for most other processors that have illegal instructions.)

06 is the lowest-numbered byte of machine code that does not correspond to a defined instruction on an x86_64 processor. So all we have to do is execute it. (Alternatively, 2F is also undefined, and corresponds to a single printable ASCII character.) Neither of these are guaranteed to always be undefined, but they aren't defined as of today.

The first program here executes 2F from the read-only data segment. Most linkers aren't capable of producing a working jump from .text to .rodata (or their OS's equivalent) as it's not something that would ever be useful in a correctly segmented program; I haven't found an operating system on which this works yet. You'd also have to allow for the fact that many compilers want the string in question to be a wide string, which would require an additional L; I'm assuming that any operating system that this works on has a fairly outdated view of things, and thus is building for a pre-C94 standard by default. It's possible that there's nowhere this program works, but it's also possible that there's somewhere this program works, and thus I'm listing it in this collection of more-dubious-to-less-dubious potential answers. (After I posted this answer, Dennis also mentioned the possibility main[]={6} in chat, which is the same length, and which doesn't run into problems with character width, and even hinted at the potential for main=6; I can't reasonably claim these answers as mine, as I didn't think of them myself.)

The second program here executes 06 from the read-write data segment. On most operating systems this will cause a segmentation fault, because writable data segments are considered to be a bad design flaw that makes exploits likely. This hasn't always been the case, though, so it probably works on a sufficiently old version of Linux, but I can't easily test it.

The third program executes 06 from the stack. Again, this causes a segmentation fault nowadays, because the stack is normally classified as nonwritable for security reasons. The linker documentation I've seen heavily implies that it used to be legal to execute from the stack (unlike the preceding two cases, doing so is occasionally useful), so although I can't test it, I'm pretty sure there's some version of Linux (and probably other operating systems) on which this works.

Finally, if you give -Wl,-z,execstack (15 byte penalty) to gcc (if using GNU ld as part of the backend), it will explicitly turn off executable stack protection, allowing the third program to work and give an illegal operation signal as expected. I have tested and verified this 49-byte version to work. (Dennis mentions in chat that this option apparently works with main=6, which would give a score of 6+15. I'm pretty surprised that this works, given that the 6 blatantly isn't on the stack; the link option apparently does more than its name suggests.)

• On x86-64/linux with gcc6 in its default (lenient) mode, const main=6; works, as do several variations. This linker (which I suspect is also your linker) is capable of generating a jump from .text to .rodata; the problem you were having is that, without const, you're jumping into the writable data segment (.data), which is not executable on modern hardware. It would have worked on older x86, where the memory protection hardware could not mark pages as readable-but-not-executable. – zwol Nov 20 '16 at 16:19
• Note that even in C89, main is required to be a function (§5.1.2.2.1) -- I don't know why gcc considers declaring main as a data object to only deserve a warning, and only with -pedantic on the command line. Someone back in the early 1990s perhaps thought that nobody would do that by accident, but it's not like it's a useful thing to do on purpose except for this sort of game. – zwol Nov 20 '16 at 16:25
• ... Rereading again, it seems you expected main[]="/" to jump to the read-only data segment, because string literals go in rodata. You've been caught out by the difference between char *foo = "..." and char foo[] = "...". char *foo = "..." is syntactic sugar for const char __inaccessible1[] = "..."; char *foo = (char *)&__inaccessible1[0];, so the string literal does go in rodata, and foo is a separate, writable global variable that points to it. With char foo[] = "...", however, the entire array goes in the writable data segment. – zwol Nov 20 '16 at 17:07

# GNU as (x86_64), 3 bytes

ud2


$xxd sigill.S 00000000: 7564 32 ud2 $ as --64 sigill.S -o sigill.o ; ld -S sigill.o -o sigill

sigill.S: Assembler messages:
sigill.S: Warning: end of file not at end of a line; newline inserted
ld: warning: cannot find entry symbol _start; defaulting to 0000000000400078


$./sigill Illegal instruction $ objdump -d sigill

sigill:     file format elf64-x86-64

Disassembly of section .text:

0000000000400078 <__bss_start-0x200002>:>
400078:       0f 0b                   ud2

• There must be a way to express that in a two-byte "source"... – OrangeDog Nov 21 '16 at 17:16
• Oh, clever. I was wondering if there was a way to build this which would put the entry point at the start of the file (with no declarations) and which wouldn't incur penalties for an unusual build system configuration. I couldn't find one, but it looks like you did. – user62131 Nov 22 '16 at 0:57
• @ais523: yeah, my usual NASM / YASM build-script (asm-link) for single-file toy programs would build an executable from this source the same way, since ld defaults the entry point to the start of the text segment or something like that. I just didn't think of going for asm source size on this one :P – Peter Cordes Nov 24 '16 at 9:21

## Bash on Raspbian on QEMU, 4 (1?) bytes

Not my work. I merely report the work of another. I'm not even in a position to test the claim. Since a crucial part of this challenge seems to be finding an environment where this signal will be raised and caught, I'm not including the size of QEMU, Raspbian, or bash.

On Feb 27, 2013 8:49 pm, user emlhalac reported "Getting 'illegal instruction' when trying to chroot" on the Raspberry Pi fora.

ping


producing

qemu: uncaught target signal 4 (Illegal instruction) - core dumped
Illegal instruction (core dumped)


I imagine much shorter commands will produce this output, for instance, tr.

EDIT: Based on @fluffy's comment, reduced the conjectured lower bound on input length to "1?".

• I'd think the [ command would win. :) – fluffy Nov 21 '16 at 22:40

# x86 MS-DOS COM file, 2 bytes

EDIT: As pointed out in the comments, DOS itself will not trap the CPU exception and will simply hang (not just the app, the entire OS). Running on a 32-bit NT-based OS such as Windows XP will, indeed, trigger an illegal instruction signal.

0F 0B


From the documentation:

Generates an invalid opcode. This instruction is provided for software testing to explicitly generate an invalid opcode.

Which is pretty self-explanatory. Save as a .com file, and run in any DOS emulator DOS emulators will just crash. Run on Windows XP, Vista, or 7 32-bit.

• It technically does cause the processor to generate an illegal instruction exception. However, DOS has very limited memory protection and exception handling capabilities, and I wouldn't be surprised if it just lead to undefined behavior / OS crash. The OP didn't say the kernel had to catch the error and print "Illegal Instruction" to the console. – maservant Nov 20 '16 at 20:45
• I thought of this solution, but I don't believe it's valid. The question requires an illegal instruction signal, not just an illegal instruction processor trap, so the aim was to find an operating system which would actually generate a signal in response to the #UD trap. (Also, I decided to actually test it, and it appeared to throw my DOS emulator into an infinite loop.) – user62131 Nov 20 '16 at 22:14
• I tested this on actual MS-DOS on an AMD K6-II. Running it just hangs the system, both with and without EMM386 running. (EMM386 traps some errors and halts the system with a message, so it was worth testing to see if it made a difference.) – Mark Nov 21 '16 at 1:43
• Yes, DOS-based windows should be able to really catch the trap and at least crash the app. – Asu Nov 23 '16 at 18:05
• @Asu I can confirm that this works on XP 32-bit, and will probably work on all other 32-bit Windows systems. I agree that this isn't a solution on DOS itself, as it just crashes. – maservant Nov 23 '16 at 22:00

# C (32-bit Windows), 34 bytes

f(i){(&i)[-1]-=9;}main(){f(2831);}


This only works if compiling without optimizations (else, the illegal code in the f function is "optimized out").

Disassembly of the main function looks like this:

68 0f 0b 00 00    push 0b0f
e8 a1 d3 ff ff    call _f
...


We can see that it uses a push instruction with a literal value 0b0f (little-endian, so its bytes are swapped). The call instruction pushes a return address (of the ... instruction), which is situated on the stack near the parameter of the function. By using a [-1] displacement, the function overrides the return address so it points 9 bytes earlier, where the bytes 0f 0b are.

These bytes cause an "undefined instruction" exception, as designed.

a->a.exec("kill -4 $$");  This is a java.util.function.Consumer<Runtime>1 whose command is stolen from fluffy's answer. It works because you must call it as whateverNameYouGiveIt.accept(Runtime.getRuntime())! Note that this will create a new process and make it throw a SIGILL rather than throwing a SIGILL itself. 1 - Technically, it can also be a java.util.function.Function<Runtime, Process> because Runtime#exec(String) returns a java.lang.Process which can be used to control the process you just created by executing a shell command. For the sake of doing something more impressive in such a verbose language, here's a 72 60 48-byte bonus: a->for(int b=0;;b++)a.exec("sudo kill -s 4 "+b);  This one is another Consumer<Runtime> that goes through ALL processes (including itself), making each of them throw a SIGILL. Better brace for a violent crash. And another bonus (a Consumer<ANYTHING_GOES>), which at least pretends to throw a SIGILL in 20 bytes: a->System.exit(132);  # Perl, 9 bytes kill+4,$$


Simply calls the appropriate library function for signalling a process, and gets the program to signal itself with SIGILL. No actual illegal instructions are involved here, but it produces the appropriate result. (I think this makes the challenge fairly cheap, but if anything's allowed, this is the loophole you'd use…)

• Came here to post the same, with a space instead of the +. :) – simbabque Nov 21 '16 at 13:16
• When people learn Perl for non-golf programming, they learn it with a +. After golfing for a while, they do + occasionally to show off. Eventually, they've written enough programs where they needed to avoid whitespace for some reason or other that the + becomes habit. (It also parses less ambiguously, because it works around triggering the special case in the parser for parentheses.) – user62131 Nov 21 '16 at 13:33

# ARM Unified Assembler Language (UAL), 3 bytes

nop


For example:

$as ill.s -o ill.o$ ld ill.o -o ill
ld: warning: cannot find entry symbol _start; defaulting to 00010054
$./ill Illegal instruction  After executing nop, the processor interprets the .ARM.attributes section as code and encounters an illegal instruction somewhere there: $ objdump -D ill

ill:     file format elf32-littlearm

Disassembly of section .text:

00010054 <__bss_end__-0x10004>:
10054:       e1a00000        nop                     ; (mov r0, r0)

Disassembly of section .ARM.attributes:

00000000 <.ARM.attributes>:
0:   00001341        andeq   r1, r0, r1, asr #6
4:   61656100        cmnvs   r5, r0, lsl #2
8:   01006962        tsteq   r0, r2, ror #18
c:   00000009        andeq   r0, r0, r9
10:   01080106        tsteq   r8, r6, lsl #2


Tested on a Raspberry Pi 3.

• Somehow this doesn't work on a Pi 2. – Mega Man Mar 5 '17 at 7:50

# Microsoft C (Visual Studio 2005 onwards), 16 bytes

main(){__ud2();}


I can't easily test this, but according to the documentation it should produce an illegal instruction by intentionally trying to execute a kernel-only instruction from a user-mode program. (Note that because the illegal instruction crashes the program, we don't have to try to return from main, meaning that this K&R-style main function is valid. Visual Studio never having moved on from C89 is normally a bad thing, but it came in useful here.)

• Can you compile for linux with VS2015? Because I do not think SIGILL is defined in Windows, is it? – Andrew Savinykh Nov 22 '16 at 3:59

# Ruby, 13 bytes

kill -4 #$$  I guess it's safe to assume that we are running this from a *nix shell. The backtick literals runs the given shell command. $$ is the running Ruby process, and the # is for string interpolation.

Without calling the shell directly:

Process.kill 4,$$ # Any shell (sh, bash, csh, etc.), any POSIX (10 bytes) Trivial answer but I hadn't seen anyone post it. kill -4$$


Just sends SIGILL to the current process. Example output on OSX:

bash-3.2kill -4 $$Illegal instruction: 4  • You could do kill -4 1 if the question isn't specific about which program throws the SIGILL – Mark K Cowan Nov 22 '16 at 23:06 • @MarkKCowan Heh, good point, although that assumes root... – fluffy Nov 23 '16 at 1:18 • You will have root in your programs - knock a byte off your answer and troll the question slightly at the same time :D. BONUS: You get to kill init – Mark K Cowan Nov 23 '16 at 12:52 • @MarkKCowan: On (modern versions of?) Linux, init is actually immune to signals that it hasn't specifically requested to receive, even with root. You could perhaps work around this by using a different POSIX OS, though. – user62131 Nov 23 '16 at 21:09 • kill -4 2 then :D – Mark K Cowan Nov 23 '16 at 21:11 # ELF + x86 machine code, 45 bytes This should be the smallest executable program on an Unix machine that throws SIGILL (due to Linux not recognizing the executable if made any smaller). Compile with nasm -f bin -o a.out tiny_sigill.asm, tested on an x64 virtual machine. Actual 45 bytes binary: 0000000 457f 464c 0001 0000 0000 0000 0000 0001 0000020 0002 0003 0020 0001 0020 0001 0004 0000 0000040 0b0f c031 cd40 0080 0034 0020 0001  Assembly listing (see source below): ;tiny_sigill.asm BITS 32 org 0x00010000 db 0x7F, "ELF" ; e_ident dd 1 ; p_type dd 0 ; p_offset dd$$ ; p_vaddr dw 2 ; e_type ; p_paddr dw 3 ; e_machine dd _start ; e_version ; p_filesz dd _start ; e_entry ; p_memsz dd 4 ; e_phoff ; p_flags _start: ud2 ; e_shoff ; p_align xor eax, eax inc eax ; e_flags int 0x80 db 0 dw 0x34 ; e_ehsize dw 0x20 ; e_phentsize db 1 ; e_phnum ; e_shentsize ; e_shnum ; e_shstrndx filesize equ - 


Disclaimer: code from the following tutorial on writing the smallest assembly program to return a number, but using opcode ud2 instead of mov: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

• I was gonna post a modified executable of that exact tutorial, but you beat me to it. This deserves to win; It's a true minimalist in the system resources sense (It requires no more than 45 bytes both in-file and in-memory, and is exactly the same in both), and no bloated interpreter like the other assembler solutions. It simply is what it is. – Iwillnotexist Idonotexist Nov 27 '16 at 7:12

# AutoIt, 93 bytes

Using flatassembler inline assembly:

#include<AssembleIt.au3>
Func W()
_("use32")
_("ud2")
_("ret")
EndFunc
_AssembleIt("int","W")


When run in SciTE interactive mode, it'll crash immediately. The Windows debugger should popup for a fraction of a second. The console output will be something like this:

--> Press Ctrl+Alt+Break to Restart or Ctrl+Break to Stop
0x0F0BC3
!>14:27:09 AutoIt3.exe ended.rc:-1073741795


Where -1073741795 is the undefined error code thrown by the WinAPI. This can be any negative number.

Similar using my own assembler LASM:

#include<LASM.au3>
$_=LASM_ASMToMemory("ud2"&@CRLF&"ret 16") LASM_CallMemory($_,0,0,0,0)


# NASM, 25 bytes

I don't know how this works, just that it does on my computer specifically (Linux x86_64).

global start
start:
jmp 0


Compile & run like:

\$ nasm -f elf64 ill.asm && ld ill.o && ./a.out
ld: warning: cannot find entry symbol _start; defaulting to 0000000000400080
Illegal instruction

• You can probably shorten it to four bytes, as ja 0 – Mark K Cowan Nov 23 '16 at 12:57
• or three as ud2 – Mark K Cowan Nov 23 '16 at 12:58
• Probably because it's trying to jump to some data? – Asu Nov 23 '16 at 18:06

# TI-83 Hex Assembly, 2 bytes

PROGRAM:I
:AsmPrgmED77


Run as Asm(prgmI). Executes the illegal 0xed77 opcode. I count each pair of hex digits as one byte.

# Python, 32 bytes

from os import*;kill(getpid(),4)

• Same byte count: import os;os.kill(os.getpid(),4) – Oliver Ni Nov 21 '16 at 20:02

# x86 .COM, 1 byte

c


ARPL causes #UD in 16-bit mode

# Linux shell, 9 bytes

kill -4 0


Sends SIGILL to the process with PID 0. I don't know what process has PID 0, but it always exists.

Try it online!

• From man kill: 0 All processes in the current process group are signaled. – Dennis Feb 27 '18 at 4:17

# GNU C, 2419 18 bytes

-4 thanks to Dennis
-1 thanks to ceilingcat

main(){goto*&"'";}


Try it online! This assumes ASCII and x86_64. It attempts to run the machine code 27, which ... is illegal.

# shortC, 105 4 bytes

AV"'


Equivalent to the GNU C code above. Try it online!

• L"\6" is also illegal, assuming x86_64. – Dennis Feb 27 '18 at 4:20
• @Dennis What instruction is 0x06? Also, the L is not necessary. – MD XF Feb 27 '18 at 16:52
• It's unassigned. – Dennis Feb 27 '18 at 17:15
• It's unassigned; that's what makes it illegal. Also, ' is 39 = 0x27, not 0x39. – Dennis Mar 2 '18 at 3:49

# MachineCode on x86_64, 2 1 bytes

7


Try it online!

Simply calls the x86_64 instruction 0x07 (ceilingcat suggested 0x07 instead of 0x27)