CSc 352 Signal Handling in Unix Saumya Debray Dept. of Computer Science The University of Arizona, Tucson

Signals A signal is a mechanism for notifying a program that some event has occurred. – intuition: signal  “software interrupt” – when a signal is sent to a program, its normal execution is interrupted – depending on (1) the state of the program, and (2) the type of signal, the program may enter some pre-specified signal handler; or take some default action. 2

Example Signals (not a complete list) Signal NameNumberDescription SIGHUP1Hangup (POSIX) SIGINT2Terminal interrupt (ANSI) SIGQUIT3Terminal quit (POSIX) SIGILL4Illegal instruction (ANSI) SIGTRAP5Trace trap (POSIX) SIGFPE8Floating point exception (ANSI) SIGKILL9Kill(can't be caught or ignored) (POSIX) SIGSEGV11Invalid memory segment access (ANSI) SIGTERM15Termination (ANSI) SIGSTKFLT16Stack fault SIGSTOP19Stop executing(can't be caught or ignored) (POSIX) SIGPROF27Profiling alarm clock (4.2 BSD) SIGWINCH28Window size change (4.3 BSD, Sun) SIGPWR30Power failure restart (System V) ……… 3

Synchronous vs. Asynchronous Signals Synchronous signals: – arise from executing an instruction in the process’s instruction stream e.g.: illegal instruction (SIGILL); illegal address (SIGSEGV) – causes a trap into the OS kernel trap handler sometimes referred to as “traps” – directed to the process/thread that executed the instruction Asynchronous signals: – source is external to the current execution e.g.: profiling clock (SIGPROF); terminal interrupt, ^C (SIGINT) 4

What’s going on: A high-level view Signal sending: – OS kernel updates info for destination process Signal receiving: – kernel forces target process to handle signal Pending signals are sent but not yet received A process can block some signals 5 Operating system kernel processes devices signals interrupts

Dealing with Signals The way in which a process deals with a given signal is called the disposition of that signal in that process. Possible dispositions: – ignore – default different for different signals – programmer-specified handler Exceptions: SIGKILL and SIGSTOP – defaults cannot be changed for these 6

Specifying a Signal Handler 7

8 changes the signal handler

Specifying a Signal Handler 9 signal number (can’t be SIGKILL or SIGSTOP)

Specifying a Signal Handler 10 info about new handler)

Specifying a Signal Handler 11 if non-NULL, where to save old handler info

Specifying a Signal Handler 12 pointer to handler function: void handler(int signal_num) or SIG_DFL or SIG_IGN

Specifying a Signal Handler 13 specifies handler if sa_flags contains SA_SIGINFO

Specifying a Signal Handler 14 specifies signals that should be blocked while the handler is executing

A Simple Example 15 structure to hold info about handler

A Simple Example 16 signal handler function

A Simple Example 17 specifying the handler

A Simple Example 18 didn’t change the default signal handler NULL pointer dereference produces a Segmentation fault

A Simple Example 19 signal handler changed but why does it get executed over and over?

Behind the scenes of a SIGSEGV When a program tries to access a bad address: – execution traps into the OS kernel – if no handler is specified: kernel invokes the default handler default handler prints out “Segmentation fault” and kills the process – if a handler is specified: kernel executes the handler – the expectation is that the handler fixes the problem restarts the offending operation – this allows programmer-controlled recovery from errors 20

Another Example: weird factorial 21 no base case???

weird factorial: cont’d 22 j =  x = x * y i = 0 y-1

weird factorial: cont’d 23 j = 1 * 2 * … * n = n!

weird factorial: cont’d 24 signal handler for SIGSEGV (signal raised by dereferencing a bad pointer in factorial() ) sets k = n! prints out k = n! and exits

Sending signals A program can send a signal to another program using the kill() system call: int kill(pid_t pid, int sig) sends the signal number sig to process pid (see /usr/include/asm-generic/signal.h) A user can send a signal from the command line using the kill command: kill –N pid E.g., “kill -9 pid”(9 = SIGKILL) 25

Asynchronous signals 26 SIGINT will be handled by my_handler() send SIGINT to process with process-id = target

Asynchronous signals – cont’d 27

Blocking signals Each process has a list (bit-vector) of blocked signals – when a signal is blocked, it remains pending Related system calls: – sigprocmask(2) system call changes the list of blocked signals – sigpending(2) shows which signals are (blocked and) pending – sigsuspend(2) suspends the calling process until the specified signal is received 28

Signal voodoo When a process forks off a child, it may want to hear back about how things went – when the child process exits, it becomes a zombie until its exit status is reported to the parent process – when something interesting happens to the child (it exits, crashes, stops, etc.), a SIGCHLD signal is sent to its parent – the parent can use the wait() system call (or variants) to find the child’s exit status If the parent is not interested, it can use sigaction() to explicitly specify that SIGCHLD should be ignored 29