| Description | Illegal instruction | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Default action | Abnormal termination of the process | ||||||||||||||||
| SA_SIGINFO macros | |||||||||||||||||
|
|||||||||||||||||
On POSIX-compliant platforms, SIGILL is the signal sent to a process when it attempts to execute a malformed, unknown, or privileged instruction. 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.
Contents |
SIG is a common prefix for signal names; ILL is an abbreviation for illegal instruction.
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.
Like all signals, 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.
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.
typedef void(*FUNC)(void); int main(void) { const static unsigned char insn[4] = { 0xff, 0xff, 0xff, 0xff }; FUNC function = (FUNC) 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 of the instruction would normally be displayed there.
Compare the output from SIGILL with that of a segmentation fault and a SIGFPE signal.
|
||||||||