Exceptional Control Flow Part II

1. Exceptional Control FlowPart II • Topics • Exec calls • Shells • Signals • Nonlocal jumps

2. Argument Lists • Given the following definition of main: • int main(int argc, char *argv[ ]); • Parameter argv is a pointer to an array of argc items. • If this main for “ls”, then the following diagram shows • ls –lt /usr/include argv[] argv argv[0] "ls" argv[1] "-lt" argv[2] argc = 3 NULL "/usr/include"

3. Environment Lists • Given the following definition of main: • int main(int argc, char *argv[ ], char *envp[ ]); • Parameter envp is a pointer to an array of environment variables. envp[] envp envp[0] "PWD=/usr/droh" envp[1] "PRINTER=iron" ... envp[n-1] NULL "USER=droh"

4. 0xbfffffff Bottom of stack StackOrganization Null-terminated environment variable strings Null-terminated command-line arg strings • main(argc,argv,envp) (Unused) envp[n] == NULL envp[n-1] ... environ envp[0] argv[argc] = NULL argv[argc-1] ... argv[0] (Dynamic linker variables) envp argv argc 0xbffffa7c Stack frame for main Top of stack

5. Demo ch08/env

6. exec: Running new programs • int execl(char *path, char *arg0, char *arg1, …, 0) • loads and runs executable at path with args arg0, arg1, … • path is the complete path of an executable • arg0 becomes the name of the process • typically arg0 is either identical to path, or else it contains only the executable filename from path • “real” arguments to the executable start with arg1, etc. • list of args is terminated by a (char *)0 argument • returns -1 if error, otherwise doesn’t return! main() { if (fork() == 0) { execl("/usr/bin/cp", "cp", “file1", “file2", 0); } wait(NULL); printf("copy completed\n"); exit(); }

7. Demo ch08/exec

8. exec: Many Flavors • There are six different exec calls. They can be distinguished by their suffixes. • “l”, for list form: arg0, arg1, ..., 0 • “v”, for vector form: argv[ ] • “e”, for passing the environment as envp[ ]. Non-e functions can call getenv, or use the environ variable. • “p”, uses the PATH environment variable to find filename. execl(pathname, arg0, arg1, ..., 0) execv(pathname, argv[]) execle(pathname, arg0, arg1, ..., 0, envp[]) execve(pathname, argv[], envp[]) execlp(filename, arg0, arg1, ..., 0) execvp(filename, argv[])

9. Multitasking and Shells

10. Multitasking • System Runs Many Processes Concurrently • Process: executing program • State consists of memory contents and register values, including EIP and EFLAGS • Continually switches from one process to another • Suspend process when it needs I/O resource or timer event occurs • Resume process when I/O available or given scheduling priority • Appears to users as if all processes executing simultaneously • Even though most systems can only execute one process at a time • Lower performance than if running alone

11. Programmer’s Model of Multitasking • Basic Functions • fork() spawns new process • Called once, returns twice • exit() terminates own process • Called once, never returns • Puts it into “zombie” status • wait() and waitpid() wait for and reap terminated children • execl() and execve() run a new program in an existing process • Called once, (normally) never returns

12. Writing a Shell • A shell is an application program that runs programs on behalf of the user. • sh – Original Unix Bourne Shell • csh – BSD Unix C Shell, tcsh – Enhanced C Shell • bash – Bourne-Again Shell • With fork and exec we can build a primitive shell. • Read a command • Parse command and convert parameters to argv[ ] array • Fork to create child process • Child process calls exec, passes argv[ ] to start program • If foreground process, parent waits for child to finish

13. Demo, ch08/shell

14. Problem with Simple Shell Example • Shell correctly waits for and reaps foreground jobs. • But what about background jobs? • Will become zombies when they terminate. • Will never be reaped because shell (typically) will not terminate. • Creates a memory leak that will eventually crash the kernel when it runs out of memory. • Solution: Reaping background jobs requires a mechanism called a signal.

15. Signals

16. Signals • A signal is a small message that notifies a process that an event of some type has occurred in the system. • Kernel abstraction for exceptions and interrupts. • Sent from the kernel (sometimes at the request of another process) to a process. • Different signals are identified by small integer ID’s • The only information in a signal is its ID and the fact that it arrived.

17. Signal Concepts • List of Signals • /usr/include/sys/signal.h (32 signals) • Sending a signal • Kernel sends (delivers) a signal to a destination process by updating some state in the context of the destination process. • Kernel sends a signal for one of the following reasons: • Kernel has detected a system event such as divide-by-zero (SIGFPE) or the termination of a child process (SIGCHLD) • Another process has invoked the kill system call to explicitly request the kernel to send a signal to the destination process.

18. Signal Concepts • Receiving a signal • A destination process receives a signal when it is forced by the kernel to react in some way to the delivery of the signal. • Three possible ways to react: • Ignore the signal (do nothing) • Terminate the process. • Catch the signal by executing a user-level function called a signal handler. • Akin to a hardware exception handler being called in response to an asynchronous interrupt.

19. Signal Concepts • A signal is pending if it has been sent but not yet received. • There can be at most one pending signal of any particular type. • Important: Signals are not queued • If a process has a pending signal of type k, then subsequent signals of type k that are sent to that process are discarded. • A process can block the receipt of certain signals. • Blocked signals can be delivered, but will not be received until the signal is unblocked. • A pending signal is received at most once.

20. Signal Concepts • Kernel maintains pending and blocked bit vectors in the context of each process. • SigPnd – set of pending signals • Kernel sets bit k in pending whenever a signal of type k is delivered. • Kernel clears bit k in pending whenever a signal of type k is received • No queue! • SigBlk – set of blocked signals • kernel blocks before calling handler, unblocks when done • application can change with sigprocmask function. • Demo (jupiter) • /proc/uptime (uptime) • /proc/cpuinfo (dmesg – L1, L2 cache size) • /proc/*/status (view files)

21. Receiving Signals • When the kernel is ready to pass control to process p... • It computes pnb = pending & ~blocked • The set of pending nonblocked signals for process p • If (pnb) • Choose least significant nonzero bit k in pnb and force process p to receive signal k. • The receipt of the signal triggers some action by p • Repeat for all nonzero k in pnb. • Pass control to next instruction in logical flow for p. • else • Pass control to next instruction in the logical flow for p.

22. Default Actions (p. 618) • Each signal type has a predefined default action, which is one of: • The process terminates • SIGINT (Ctrl-C), SIGKILL (kill program) • The process terminates and dumps core • SIGFPE (floating point exception), SIGABORT (abort function) • The process stops until restarted • SIGTSTP/SIGCONT (Ctrl-S, Ctrl-Q) • The process ignores the signal

23. Installing Signal Handlers • The signal function modifies the default action associated with the receipt of signal signum: • handler_t *signal(int signum, handler_t *handler) • Different values for handler: • SIG_IGN: ignore signals of type signum • SIG_DFL: revert to the default action on receipt of signals of type signum. • Otherwise, handler is the address of a signal handler • Called when process receives signal of type signum • Referred to as “installing” the handler. • Executing handler is called “catching” or “handling” the signal. • When the handler executes its return statement, control passes back to instruction in the control flow of the process that was interrupted by receipt of the signal.

24. Process Groups • Every process belongs to exactly one process group. By default, child inherits process group of parent. Shell pid=10 pgid=10 Fore- ground job Back- ground job #1 Back- ground job #2 pid=20 pgid=20 pid=32 pgid=32 pid=40 pgid=40 Background process group 32 Background process group 40 Child Child • getpgrp() – Return process group of current process • setpgid() – Change process group of a process pid=21 pgid=20 pid=22 pgid=20 Foreground process group 20

25. Sending Signals with kill Command • The kill command sends any signal to a process or process group. • Examples • kill –l (list signals) • kill –9 24818 • Send SIGKILL to process 24818 • kill –9 –24817 • Send SIGKILL to every process in process group 24817. • Demo • ch08/sig/killsig 1-5 • ch08/sig/forks 12-13

26. Signal Handler Funkiness • May lose signals • no queue • handler called when at least one process needs to be reaped • solution? void child_handler(int sig) { int child_status; pid_t pid = wait(&child_status); printf("Received signal %d from process %d\n", sig, pid); }

27. Loop until all signals caught • Some interesting demos • ch08/sig/alarm • ch08/sig/stop void child_handler(int sig) { int child_status; pid_t pid; while ((pid = wait(&child_status)) > 0) { ccount--; printf("Received signal %d from process %d\n", sig, pid); } }

28. Remember the Shell? void eval(char *cmdline) { char *argv[MAXARGS]; // argv for execve() int bg; // should the job run in bg or fg? pid_t pid; // process id bg = parseline(cmdline, argv); if (!builtin_command(argv)) { if ((pid = Fork()) == 0) { // child runs user job if (execve(argv[0], argv, environ) < 0) { printf("%s: Command not found.\n", argv[0]); exit(0); } } if (!bg) { // parent waits for fg job to terminate int status; if (waitpid(pid, &status, 0) < 0) unix_error("waitfg: waitpid error"); } else // otherwise, don’t wait for bg job printf("%d %s", pid, cmdline); } } • Kernel sends SIGCHLD signal to parent when child exits • Install SIGCHLD handler in parent to reap process

29. Non-local Jumps

30. Try-Catch in C++ int divide(int num, int den ) { if (den == 0) throw logic_error(“divide by zero”); return num/den; } void process( ) { ... int q = divide(3, 0); } int main( ) { try { process( ); } catch (const logic_error& e) { cerr << e.what( ) << endl; } } • How do we transfer control from throw to catch?

31. setjmp/longjmp • A user-level mechanism for transferring control to an arbitrary location. • Way to break the procedure call/return discipline • Useful for error recovery and signal handling • int setjmp(jmp_buf j) • Save registers, including ESP/EIP in jmp_buf • Return twice. First time 0, second time returns rc from longjmp • void longjmp(jmp_buf j, int rc) • Restore registers from jmp_buf • Set %eax (the return value) to rc • Jump to the location indicated by the EIP stored in jump jmp_buf • Causes original setjmp to return rc

32. setjmp/longjmp #include <setjmp.h> jmp_buf buf; main() { if (!setjmp(buf)) { printf(“first time through\n"); else printf(“back in main due to error\n"); p1(); // p1 calls p2, which calls p3 } ... p3() { <error checking code> if (error) longjmp(buf, 1) }

33. sigsetjmp/siglongjmp • Use the following calls for long jumps from handlers: • sigsetjmp(sigjmp_buf, 1) // 1 = save signal vectors • siglongjmp(buf, rc) • Demo • ch08/sig/restart

34. Limitations of Long Jumps • Works within stack discipline • Can only long jump to environment of function that has been called but not yet completed env jmp_buf env; P1() { if (setjmp(env)) { /* Long Jump to here */ } else { P2(); } } P2() { . . . P2(); . . . P3(); } P3() { longjmp(env, 1); } P1 P1 P2 After longjmp P2 P2 P3 Before longjmp

35. P1 P1 P2 env env P2 At setjmp X P2 returns P1 env P3 X At longjmp Limitations of Long Jumps • Works within stack discipline • Can only long jump to environment of function that has been called but not yet completed jmp_buf env; P1() { P2(); P3(); } P2() { if (setjmp(env)) { /* Long Jump to here */ } } P3() { longjmp(env, 1); }

36. Try-Catch in C++ int divide(int x, int y ) { if (den == 0) throw logic_error(“divide by zero”); return x/y; } void process( ) { ... q = divide(3, 0); } int main( ) { try { process( ); } catch (const logic_error& e) { cerr << e.what( ) << endl; } } • Implementation? • try: setjmp • throw: longjmp • Other issues • stack unwinding calls destructors • must match throw-catch type

37. Summary • Signals provide process-level exception handling • Can generate from user programs • Can define effect by declaring signal handler • Some caveats • Very high overhead • >10,000 clock cycles • Only use for exceptional conditions • No queues • Just one bit for each pending signal type • Nonlocal jumps provide exceptional control flow within process • Within constraints of stack discipline