1 / 29

CSc 352 Signal Handling in Unix

CSc 352 Signal Handling in Unix. Saumya Debray Dept. of Computer Science The University of Arizona, Tucson debray@cs.arizona.edu. Signals. A signal is a mechanism for notifying a program that some event has occurred. intuition: signal  “software interrupt”

trentb
Download Presentation

CSc 352 Signal Handling in Unix

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSc 352Signal Handling in Unix Saumya Debray Dept. of Computer Science The University of Arizona, Tucson debray@cs.arizona.edu

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

  3. Example Signals (not a complete list) Signal Name Number Description SIGHUP 1 Hangup (POSIX) SIGINT 2 Terminal interrupt (ANSI) SIGQUIT 3 Terminal quit (POSIX) SIGILL 4 Illegal instruction (ANSI) SIGTRAP 5 Trace trap (POSIX) SIGFPE 8 Floating point exception (ANSI) SIGKILL 9 Kill(can't be caught or ignored) (POSIX) SIGSEGV 11 Invalid memory segment access (ANSI) SIGTERM 15 Termination (ANSI) SIGSTKFLT 16 Stack fault SIGSTOP 19 Stop executing(can't be caught or ignored) (POSIX) SIGPROF 27 Profiling alarm clock (4.2 BSD) SIGWINCH 28 Window size change (4.3 BSD, Sun) SIGPWR 30 Power failure restart (System V) … … …

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

  5. 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 processes signals Operating system kernel interrupts devices

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

  7. Specifying a Signal Handler

  8. Specifying a Signal Handler changes the signal handler

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

  10. Specifying a Signal Handler info about new handler)

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

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

  13. Specifying a Signal Handler specifies handler if sa_flags contains SA_SIGINFO

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

  15. A Simple Example structure to hold info about handler

  16. A Simple Example signal handler function

  17. A Simple Example specifying the handler

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

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

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

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

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

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

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

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

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

  27. Asynchronous signals – cont’d

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

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

More Related