I220A-Lab 6 Solved

Exercise 1: Observing Process Memory

This exercise demonstrates how one can monitor the memory size of a process under Unix systems.

Change over to the directory process-memory. Build the process-memory program by typing make. The program simply allocates argv[1] MB of memory and then sleeps for 1 minute.

Run the program but put it in the background using a trailing & by typing something like ./process-memory 10 &. The system will output two numbers followed by the command-line prompt; the rst number enclosed within square brackets [] is is the job id and the second number is the process id or PID. This will be followed by a message from the background process saying that memory was allocated.

You can get back a fresh command-line prompt by simply typing a return.

Given the PID pid for the process, look at the memory size of the process using ps -Fp PID. You will get a couple of lines printed out: a header followed by the values for the speci ed process. Do man ps to get the ps man page; the relevant elds for memory are SZ which gives the total size of the process (in pages) and RSS which gives the number of pages which are resident in memory.

Repeat with ./process_memory 100 & and observe the increase in SZ, whereas the RSS stays roughly the same since the allocated memory is totally inactive.

Note that when the background processes you started using the & shell operator terminate, the shell will print a message on your terminal.

1.3.3             Exercise 2: Buggy Program

Change over to the directory bug-program where bug-program.c contains four memory allocation bugs. Look at the program which should be reasonably understandable.

Build the program by typing make. Even with the multiple bugs, the program will probably run without a problem!! The fact that it may do so illustrate the insiduous nature of such bugs in that such buggy programs seem to work most of the time.

Can you understand why the indexes of the words are printed out in descending order?

The following sections will introduce tools which will help you spot the bugs, but see if you can nd one-or-more bugs without using the tools. Some hints:

•    The amount of memory needed to store a string must include space for the terminating ’\0 NUL‘ character.

•    When malloc()’ing memory for some type T, the normal call will look like T *pointerToT = malloc(sizeof(T));.

•    All allocated memory should be free()’d. Hence for every memory allocation call there should be a call to free().

•    Memory should not be accessed once it has been free()’d.

1.3.4                Exercise 3: Using Heap-Consistency Checking

Stay in the bug-program directory, but now run the program using

$ MALLOC_CHECK_=1 ./bug-program

[Note the trailing underscore in MALLOC_CHECK_].

The program should run ok, but the program output should also be followed by memory diagnostics (and possibly terminate with a segmentation fault). The way this works is that setting the MALLOC_CHECK_ environmental variable links in a special version of the C library which does some consistency checking on the memory allocations. In the above case it may report some inconsistencies.

Look at the listed inconsistencies, and see if you can nd any of the bugs which result in the memory inconsistency. Possibly ring up gdb and tracing the operation of the program may help.

1.3.5            Exercise 4: Using valgrind

You may or may not have been successful in xing memory allocation bugs in the previous exercise. The problem with the diagnostics produced in that exercise is that they did not point you to speci c source lines. An alternative is to use the valgrind tool which produces much better diagnostics at the source level.

Stay in the bug-program directory, but now run the program using

$ valgrind -v --leak-check=yes ./bug-program 2bug-program.valgrind

This should record the standard error diagnostics in the bug-program.valgrind le. Now look at that le and the docs for valgrind and try to gure out the bugs. Look at the speci c lines mentioned for bug-program.c to gure out the problems.

Since the report is quite long, search the le for errors mentioning bug-program¬ .c. Look at the line speci ed by the line number mentioned in valgrind report. Consider the error reported by valgrind for that line and try to nd the bug which may cause it. Note that the same bug may result in multiple errors.

Since it is very likely that each of the words in the Jabberwocky poem cause the same bugs, it may be a good idea to comment out all words other than the rst and then run valgrind once again. This way the report will be shorter and it may be easier to nd the bugs.

Once you have identi ed the bugs, x them. Run a valgrind report so that valgrind reports a clean output without any errors.