SIGILL

Infobox Computing signal
description = Illegal instruction
action = Abnormal termination of the process
ILL_ILLOPC | illegal opcode
ILL_ILLOPN | illegal operand
ILL_ADR | illegal addressing mode
ILL_ILLTRP | illegal trap
ILL_PRVOPC | privileged opcode
ILL_PRVREG | privileged register
ILL_COPROC | coprocessor error
ILL_BADSTK | internal stack error

SIGILL is the signal sent to computer programs that attempt to execute malformed, unknown, or privileged instructions on POSIX-compliant platforms. The symbolic constant for SIGILL is defined in the signal.h header file. Symbolic signal names are used because signal numbers can vary across platforms.

Etymology

"SIG" is a common prefix for signal names; "ILL" is an abbreviation for "illegal instruction".

Description

There are many possible reasons for receiving a SIGILL. A common mistake involves accidentally overwriting stack data with a return address that points to data not meant to be executed or trying to execute a function pointer that is not properly initialized. Other problems might involve compiler (toolchain) bugs, filesystem corruption or attempting to execute instructions that require special privileges.

Many platforms implement new instructions or provide additional registers on subsequent hardware revisions, so applications compiled for more recent hardware may generate "illegal instructions" when run on older hardware that does not recognise the new opcodes. An example might be attempting to use MMX instructions on an Intel 80486 processor, which didn't support the feature.

SIGILL can also be generated by users with the appropriate permissions, using the kill system call.

SIGILL can be handled. That is, programmers can specify the action they would like to occur upon receiving a SIGILL, such as execute a subroutine, ignore the event, or restore the default behaviour. BIND 8 used this mechanism to write server statistics to an external file.

Note that under certain circumstances, attempting to ignore SIGILL can result in undefined behaviour.

Sometimes bad call linkage will also cause SIGILL. In C++, passing a non-POD data type into a variadic function such as printf will cause undefined behavior; in GCC this means deliberately placing an illegal instruction at that point in the assembler.

Example

Here is an example of an ANSI C program that attempts to execute an illegal instruction on platforms where 0xFFFFFFFF is not a valid opcode.

int main(){ unsigned char insn [4] = { 0xff, 0xff, 0xff, 0xff }; void (*function)() = (void (*)()) insn; function();}

Compiling and running it on IA-32 with Linux produces the following:

$ gcc -o sigill sigill.c $ ./sigill Illegal instruction (core dumped)

On more recent processors and Linux versions, the program above may not receive a SIGILL because of the NX bit feature, that allows the Linux kernel to make the memory pages on the program stack non-executable by default. On those cases, the program will receive the SIGSEGV signal.

A backtrace from gdb shows that the program crashed within the main function when the program tried to execute an instruction at address 0xBFFFEDE4:

Program received signal SIGILL, Illegal instruction. 0xbfffede4 in ?? () (gdb) bt #0 0xbfffede4 in ?? () #1 0x0804837f in main () (gdb) x/i $pc 0xbfffede4: (bad)

Note "(bad)", indicating that the debugger does not recognize the opcode at that address. The mnemonic representing the instruction would normally be displayed there.

Compare the output from SIGILL with that of a segmentation fault and a SIGFPE signal.

See also

* Signal (computing)
* Pentium F0 bug
* Instruction set
* Ring 0