Some very simple trace files, that you should use for debugging your
code, have been provided in the following directory:

/afs/cs.cmu.edu/academic/class/15213-f02/L6/debug-traces/ 

Debug your malloc package (and your mm_heapcheck routine) on these
functions before tackling the larger default traces (use the -f
option to mdriver to test an individual trace).

Compiling mm-helper.c: Copy mm-helper.c to mm.c (save a copy of mm.c
before). Then type "make".

This file is a good starting point.  The mm-helper.c implements an
implict-list with first fit. It has an empty mm_heapcheck() function,
and it does not store request_id or payload in the allocated block. In
this implementation, the allocated block looks like the following

        -----------------------------
       |header|		      |footer|
        -----------------------------
              ^
	      |
	    old bp


while we want the allocated block to look something like this,


        ----------------------------------
       |header|id|payload|         |footer|
        ----------------------------------
			 ^
			 |
		       new bp

So, in order to get the trace file "debug-traces/t1" to work, I would
need to add the new fields to the allocated block and shift the base
pointer to the new location. 

The new OVERHEAD is 16 bytes, instead of 8 bytes. You would need to
PUT an id at (old bp), you would need to PUT the payload at (old
bp + 4), and then shift (old bp) by 8 to get (new bp).


Some notes on the trace files:

1) Ignore the first line

2) The second line is the number (n) of request ids used, request ids
   range from 0..n-1

3) The third line is the number of total calls (malloc,free,heapcheck)
   in the trace

4) Ignore the fourth line

5) 6) ...  These lines correspond to the calls which are in the
      following format:
    
    a <id> <payload> : the driver would call malloc(payload)

    f <id> : the driver would call free(ptr) where ptr was returned by
	     a previous malloc with the corresponding <id>

    c : the driver would call heapcheck

So, using this format, you can write your own small trace files for
debugging.


Heapchecker : One of the reasons for why we want you to write a
mm_heapcheck() function is that it is very useful for debugging. We
encourage you to write a very robust heap checker and call it at
various places inside your code for malloc and free to make sure that
things are fine. You might want to write an alternate static (local)
function, say mychecker(), which is like heapchecker but does not do a
lot of printing, i.e. only prints something if it encounters something
unexpected. Then you can call mychecker(), instead of mm_heapcheck(),
at numerous places inside your code when you are trying to track down
bugs in your heap. The driver function runs the trace file multiple
times for measuring performance, therefore calling mychecker() inside
your code will not clutter the screen with too much output.