CSC 357 Lab 4
Freeing Memory in Solution to Lab 2



ISSUED: Wednesday, 25 April 2007
DUE: On or before 11:59:59PM Wednesday 2 May, via handin on falcon/hornet
POINTS POSSIBLE: 100
WEIGHT: 2% of total class grade
READING: malloc/free man pages; smartallloc documentation

Overview

The following online directory for Lab 4 has a solution to Lab 2:


classes/357/labs/4/

The given implementation of general-list.c is a copious memory leaker. Your job for this lab is fix the implementation.

The solution in the Lab 4 directory has been updated to use the smartalloc memory allocation functions. These functions provide information about memory leaks, in the form of a post-mortem dump after the generatl-list-test program executes. The output consists of lines like this:

> Orphaned buffer:      20 bytes allocated at line 22 of general-list.c

This means that the 20 bytes allocated at line 22 of general-list.c where never freed. These messages go to stderr, not stdout. Hence, you can separate the computed program output from the smartalloc error messages, by redirecting stdout to a file, and viewing the smartalloc messages on the terminal.

Documentation for smartalloc is here:


classes/357/documentation/smartall.html

Helpful Hints

The memory leaks are in several areas, the specific locations of which you need to determine. The biggest leaks are clearly due to use of the newstrcat macro in the toString function. Fixing the leaks outside of toString is reasonably straightforward.

Fixing the memory leak problems related to newstrcat will take some more work. It is recommended that you rewrite newstrcat as a function instead of a macro to make the fixes easier to deal with. If you do this, put the function definition in general-list.c, and a declaration in general-list.h.

Alternatively, you can scrap the newstralloc functionality altogether, and rewrite toString in a different way. Whatever form of implementation you choose, you must dynamically allocate and free string storage. That is, you cannot declare a fixed length array to hold the returned result of toString.

Compiling and Running

There is a Makefile that compiles, executes, and tests the program. To execute the Makefile, simply type the command make at the UNIX command prompt.

When general-list-test runs, it reports any memory leaks in the form of smartalloc messages described above. To be successful, your updated solution must output no messages from smartalloc. It must also produce the same computed output as the original, leaky version of the program.

Deliverables

The minimum deliverables are updated versions of general-list.c and general-list-test.c. If you add any functions to general- list.c, which is highly recommended, then submit an appropriately modified general-list.h.

Do not modify any other .c or .h files, or the Makefile.

Scoring Details

50 points for fixing toString-related memory leaks; 50 points for fixing other leaks (which are not itemized, since you need to figure out where they are).

Collaboration Allowed

Lab partners may submit the same program.

How to Submit the Deliverables

Submit your deliverables using the handin program on falcon/hornet. The assignment name is lab4.

If lab partners elect to submit the same program, they must still run handin individually to submit their work.


index | lectures | labs | programs | handouts | solutions | examples | documentation | bin