Swift 6 (non-competing)

So, uh...

@MainActor func mainActorOnly() {
  print("Hi from the main actor!")
}

// implicitly `nonisolated`
func doStuff() async {
  DispatchQueue.main.async { @MainActor in
    MainActor.assertIsolated()
    mainActorOnly()
  }
}

await doStuff()

// MARK: - The WTF-level stuff

struct DispatchQueue {
  static let main = Self()
  func async(_ work: () -> Void) { work() }
}

This crashes with a SIGILL caused by a call to fatalError(_:file:line:) in MainActor.assertIsolated().

Details

Credit goes to this blog post for documenting this behavior. The following explanation assumes at least a basic understanding of Swift concurrency — in particular, what the "main actor" is, and what it means for code to be isolated to it.

This is a kinda big but also extremely silly hole in the implementation of Swift's concurrency model.

In short, there isn't actually any way for the compiler to prove that the closure passed to DispatchQueue.main.async (the real one from Foundation, not the impostor here) is guaranteed to be isolated to the main actor. So the type checker performs a syntax-level check for a closure passed to something called DispatchQueue.main.async, and will annotate the closure's type with @_unsafeMainActor if the check succeeds. (It should go without saying that this attribute does not perform any runtime checks on its own.)

To illustrate this, here's an example. This compiles and runs just fine (assuming that Foundation is imported, and that mainActorOnly() is a function annotated with @MainActor):

Task {
  DispatchQueue.main.async {
    mainActorOnly()
  }
}

but these don't:

Task {
  let queue = DispatchQueue.main
  queue.async {
    mainActorOnly() // error: call to main actor-isolated global function 'mainActorOnly()' in a synchronous nonisolated context
  }
}

Task {
  typealias DQ = DispatchQueue
  DQ.main.async {
    mainActorOnly() // error: call to main actor-isolated global function 'mainActorOnly()' in a synchronous nonisolated context
  }
}

This can be a little annoying, but it's not too tricky to work around when you need to. The real problem shows itself when you declare your own type named DispatchQueue, with its own static property called main and an instance method called async that takes a closure:

struct DispatchQueue {
  static let main = Self()
  func async(_ work: () -> Void) { work() }
}

Our impostor DispatchQueue.main.async is quite evidently not isolated to the main actor, neither at compile-time nor at runtime. But the Swift compiler is none the wiser, and will happily let you call main actor-isolated code via this method.

(The runtime, however, isn't quite so naive, and correctly determines that the closure passed to the fake async is nonisolated — this is why MainActor.assertIsolated() crashes in this case.)

MMIXAL, 13 bytes

Main RESUME 2

RESUME is legal in all code; RESUME 1 throws a protection violation in user mode; any other argument throws an illegal instruction violation.

Rust, 53 bytes

fn main(){unsafe{std::hint::unreachable_unchecked()}}

This piece of code generates no main function because main is marked as unreached, hence SIGILL being triggered when run. Try it online!

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

x86 .COM, 1 byte

c

ARPL causes #UD in 16-bit mode

MachineCode on x86_64, 2 1 bytes

7

Try it online!

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

GNU C, 24 19 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, 10 5 4 bytes

AV"'

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

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!

C (x86_64, tcc), 7 bytes

main=6;

Inspired by this answer.

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.

Java, 50 43 24 bytes

a->a.exec("kill -4 $$");

This is a java.util.function.Consumer<Runtime>¹ 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);

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.

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

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.

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

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.

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

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

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.2$ kill -4 $$
Illegal instruction: 4

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

Python, 32 bytes

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

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.

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.

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:

Ruby, 17 bytes

Process.kill 4,$$

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)

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

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

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.