CS 241 Section Week #2 9/9/10

2 Topics This Section MP1 issues MP2 overview Process creation using fork()‏ Debugging tools: valgrind, gdb

MP1 Issues Q: My printf prints my string correctly but appends a lot of garbage after it. Why?

MP1 Issues Q: My printf prints my string correctly but appends a lot of garbage after it. Why? A: The line probably does not have a termination char (' \0 ')

MP1 Issues Q: Why there's no '\0' at the end of my string?

MP1 Issues A: Some functions (e.g., strncpy(), strncat() ), do not add the \0 at the end of the string S: add the termination char manually: strncpy(str,src,i); str[i]='\0'; Q: Why there's no '\0' at the end of my string?

MP1 Issues What’s wrong with this code? #include int main(){ char *str = (char *) malloc(5); strcpy(str,"Hello"); printf("%s",str); }

MP1 Issues What’s wrong with this code? #include int main(){ char *str = (char *) malloc(5); strcpy(str,"Hello"); printf("%s",str); } No space for \0 ==15648== Invalid write of size 1 ==15648== at 0x : memcpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==15648== by 0x804847A: main (a.c:8) ==15648== Address 0x419802d is 0 bytes after a block of size 5 alloc'd Valgrind helps finding these errors:

MP1 Issues What’s wrong with this code? #include int main(){ int i; char str[6]; scanf("%s",str); if (!strcmp(str,"A")) i=1; if (!strcmp(str,"B")) i=2; printf("%d",i); }

MP1 Issues What’s wrong with this code? #include int main(){ int i; char str[6]; scanf("%s",str); if (!strcmp(str,"A")) i=1; if (!strcmp(str,"B")) i=2; printf("%d",i); } i might not be initialized ==15721== Conditional jump or move depends on uninitialised value(s) Valgrind helps finding these errors:

MP1 Issues What’s wrong with this code? #include void init(dictionary_t* d){ d = malloc(sizeof(dictionary_t)); d->next = NULL; } int main(){ dictionary_t dic; init(&dic) }

MP1 Issues What’s wrong with this code? #include void init(dictionary_t* d){ d = malloc(sizeof(dictionary_t)); d->next = NULL; } int main(){ dictionary_t dic; init(&dic) } STACK HEAP dic

MP1 Issues What’s wrong with this code? #include void init(dictionary_t* d){ d = malloc(sizeof(dictionary_t)); d->next = NULL; } int main(){ dictionary_t dic; init(&dic) } STACK HEAP dic

MP1 Issues What’s wrong with this code? #include void init(dict_t* d){ d = malloc(sizeof(dictionary_t)); d->next = NULL; } int main(){ dict_t dic; init(&dic) } STACK HEAP dic (dict_t*) d

MP1 Issues What’s wrong with this code? #include void init(dictionary_t* d){ d = malloc(sizeof(dictionary_t)); d->next = NULL; } int main(){ dictionary_t dic; init(&dic) } STACK HEAP dic (dict_t*) d dict_t: next=???? dict_t: next=????

MP1 Issues What’s wrong with this code? #include void init(dictionary_t* d){ d = malloc(sizeof(dictionary_t)); d->next = NULL; } int main(){ dictionary_t dic; init(&dic) } STACK HEAP dic (dict_t*) d dict_t: next = NULL dict_t: next = NULL

MP1 Issues What’s wrong with this code? #include void init(dictionary_t* d){ d = malloc(sizeof(dictionary_t)); d->next = NULL; } int main(){ dictionary_t dic; init(&dic) } STACK HEAP dic dict_t: next = NULL dict_t: next = NULL Still uninitialized Lost memory

MP1 Issues Solution: #include void init(dictionary_t* d){ d = malloc(sizeof(dictionary_t)); d->next = NULL; } int main(){ dictionary_t dic; init(&dic) } STACK HEAP dic (dict_t*) d

19 MP1 Issues What’s wrong with this code? int x; int *xptr = (int*)malloc(sizeof(int)); xptr = &x; x xptr 4 bytes Memory Lost !!!

20 MP2

MP2 overview Simple Unix shell Non built-in commands Built-in commands Change Directory Termination History Error handling Concepts needed: process, fork, exec, wait

Processes A process is an instance of a running program A process contains: Instructions (i.e. the program)‏ Resources (variables, buffers, links, etc.)‏ State (identity, ready/running/locked, etc.)‏ Processes can create other processes

fork() creates a new process: Process Creation with fork()‏ env stack free heap static code  The new (child) process is identical to the old (parent) process, except… env stack free heap static code fork()‏ creates Parent Child

Differences between parent and child Process ID ( getpid() )‏ Parent ID ( getppid() )‏ Return value of fork()‏ In parent, fork() returns child pid In child, fork() returns 0

fork() Example 1 What does this do? #include int main() { printf(“%d\n”, fork()); return 0; } Try it!

fork() example 2 #include int main() { pid_t child_pid = fork(); if (child_pid < 0) {// error code perror(“Fork Failed”); return –1; } printf(“I'm process %d\n”,getpid()); if (child_pid == 0) {// child code printf(”I’m the child of parent process %d.\n”, getppid()); } else { /* child_pid > 0 */// parent code printf(“I’m the parent of child process %d.\n”, child_pid); } return 0; }

Example 2 cont’d This exits too quickly; let’s slow it down: if (child_pid == 0) {// child code sleep(15); printf(”I’m the child of parent process %d.\n”, getppid()); } else {// parent code sleep(20); printf(”I’m the parent of child process %d.\n”, child_pid); }

Example 2 cont’d In a second window, run ps –a, and look for the pids from the program output. Periodically run ps –a again, as the program in the first window executes. – What happens when the program runs? – What happens when the child finishes? – What happens when the parent finishes? – What happens when you switch the parent and child sleep statements?

Orphans and Zombies When a process finishes, it becomes a zombie until its parent cleans up after it. If its parent finishes first, the process becomes an orphan, and the init process (id 1) adopts it.

How can a parent know when its children are done?

Solution: wait(…) wait() allows a parent to wait for its child process, and save its return value pid= wait(&status); pid= waitpid(pid, &status, options); wait() waits for any child; waitpid() waits for a specific child.

wait cont’d wait() blocks until child finishes wait() does not block if the option WNOHANG is included. When would we want to use this? The child’s return value is stored in *status

wait(...) macros WIFEXITED(status) is true iff the process terminated normally. WEXITSTATUS(status) gives the last 8 bits of the process’s return value (assuming normal exit)‏

Example 3: wait #include … // add this to parent code if (waitpid(child_pid, &result, 0) == -1) { perror(”Wait failed”); return -1; } if(WIFEXITED(result)) { fprintf(stdout, ”child %d returned %d\n”, child_pid, WEXITSTATUS(result)); }

exec exec replaces the current process image(code, variables, etc.) with that of a new program: env stack free heap static code env* New Program exec * The program may choose to change the environment BeforeAfter

exec variations There are 6 different ways of calling exec. Which one to use depends on three conditions: 1.How arguments are passed execl, execv 2.How the path is specified execlp, execvp 3.Whether a new environment is used execle, execve

exec variations: passing parameters exec can have parameters passed to it two different ways: List of parameters: execl(“/bin/ls”, ”ls”, ”-l”, NULL); Argument Vector (like argv ): execv(“/bin/ls”, argv); // char *argv[] Q: When would you use execl ? When would you use execv ?

exec variations: command path Adding a “ p ” to an exec call tells the system to look for the command in the environment’s path. Compare:  execl(“/bin/ls”, ”ls”, ”-l”, NULL);  execlp(“ls”, ”ls”, ”-l”, NULL); The difference is similar for execv and execvp.

exec variations (cont’d)‏ By default, the new program inherits the old program’s environment. Adding an “ e ” to the exec call allows the new program to run with a new environment **environ execve and execle allow the user to specify the environment. The others inherit the old environment.

fork + exec If exec succeeds, it does not return, as it overwrites the program. – No checking return values, executing multiple commands, monitoring results, etc. Solution: fork a new process, and have the child run exec

Example 4: exec int main() { char command[10]; while(fscanf(stdin, “%s”, command)) { pid_t child_pid = fork(); if (child_pid < 0) { perror("Fork failed"); return -1; } else if (child_pid == 0) { // child code // execute command // check errors } else { // parent code // What belongs here? } return 0; }

42 Debugging Tools

43 Using valgrind to check memory leak To run a program (./part1 )‏ To use valgrind ( valgrind –-leak- check=full./part1 )‏ valgrind output with no memory leak ==19376== ERROR SUMMARY: 0 errors from 0 contexts... ==19376== malloc/free: 1 allocs, 1 frees, 10 bytes allocated.... ==19376== All heap blocks were freed -- no leaks are possible.

44 valgrind output with memory leak Memory is allocated using malloc(... ) inside the function testmalloc(... )‏ ==20086== ERROR SUMMARY: 1 errors from 1 contexts... ==20086== malloc/free: 1 allocs, 0 frees, 10 bytes allocated.... ==20086== 10 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==20086== at 0x4022AB8: malloc (vg_replace_malloc.c:207)‏ ==20086== by 0x : testmalloc (in /home/farhana/test)‏ ==20086== by 0x804848A: main (in /home/farhana/test)‏... ==20086== LEAK SUMMARY: ==20086== definitely lost: 10 bytes in 1 blocks....

Preparing to use GDB Compile and link with -g option compiler includes symbolic information with object and executable files examples: type information, function and variable names Debugging optimized code (-g and -O) will work with gcc (not with most others) but gdb cannot undo optimizations if you can’t either, safer to turn off optimizer

Starting GDB before starting a program [user]$ gdb (gdb) run after starting a program [user]$ gdb or (gdb) attach use “file” command or restart gdb after recompilation

Some Basic Commands backtrace or where –show the stack trace (sequence of procedure calls) moving from one stack frame to another –up: move one frame higher –down: move one frame lower –frame : move to frame n list: show the source code corresponding to the current stack frame (by default)

Basics of Showing Program State print –evaluate an expression (usually in C/C++) –show the result display (like print) –evaluate and show result of expression –each time the program stops –returns an integer identifier undisplay : stop displaying something info locals: show the values of all variables defined within the current frame

Controlling the Program continue: let the program run at full speed one step (source line!) at a time –next step over any function calls run until the function returns and any remaining code on the line finishes –step: step into function calls, to the first line finish: run until the current frame returns return [ ]: cut the current frame short and return immediately

Using Breakpoints break [ :] –set a breakpoint –returns an integer identifier break cond disable [ ]: disable temporarily enable [ ]: re-enable delete [ ]: remove permanently info breakpoints: show all breakpoints, conditions, etc

One last command quit –Quit. –You may kill the program being debugged when you do so