Carnegie Mellon

Recitation 11: More Malloc Lab

Instructor: TA(s)

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 1

 Carnegie Mellon

Understanding Your Code

 Sketch out the heap
 Add Instrumentation
 Use tools

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 2

 Carnegie Mellon

Sketch out the Heap

 Start with a heap, in this case implicit list

0 4 4 4 4 6 6 04 4 0

 Now try something, in this case, extend_heap

block_t *block = payload_to_header(bp);
write_header(block, size, false);
write_footer(block, size, false);
// Create new epilogue header
block_t *block_next = find_next(block);
write_header(block_next, 0, true);

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 3

 Carnegie Mellon

Sketch out the Heap

 Here is a free block based on lectures 19 and 20
 Explicit pointers (will be well-defined see writeup and Piazza)
 Optional boundary tags
1 word
 If you make changes to your design beyond this
 Draw it out. Size b0
 If you have bugs, Next
pictures can help the staff help you Prev

Unallocated

Size b0

Free
Block
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 4
 Carnegie Mellon

Add Instrumentation
 Remember that measurements inform insights.
 Add temporary code to understand aspects of malloc
 Code can violate style rules or 128 byte limits, because it is
temporary

 Particularly important to develop insights into

performance before making changes
 What is expensive throughput-wise?
 How much might a change benefit utilization?

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 5

 Carnegie Mellon

Add Instrumentation example

 Searching in find_fit is often the slowest step

 How efficient is your code? How might you know?

 Compute the ratio of blocks viewed to calls
static block_t *find_fit(size_t asize)
{
block_t *block; call_count++;
for (block = heap_listp; get_size(block) > 0;
block = find_next(block))
{ block_count++;
if (!(get_alloc(block)) && (asize <= get_size(block)))
{
return block;
}
}
return NULL; // no fit found
}
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 6
 Carnegie Mellon

Add Instrumentation cont.

 What size of requests?
 How many 8 bytes or less?
 How many 16 bytes or less?
 What other sizes?

 What else could you measure? Why?

 Remember that although the system’s performance varies

 The mdriver’s traces are deterministic
 Measured results should not change between runs

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 7

 Carnegie Mellon

Use tools
 Use mm_checkheap()
 Write it if you haven’t done so already
 Add new invariants when you add new features
 Know how to use the heap checker.
 Why do you need a heap checker? 2 reasons.

 Use gdb
 You can call print or mm_checkheap whenever you want in gdb. No
need to add a while lot of printf’s.
 Offers useful information whenever you crash, like backtrace.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 8

 Carnegie Mellon

mdriver-emulate
 Testing for 64-bit address space

 Use correctly sized masks, constants, and other variables

 Be careful about subtraction between size types (may re
result in underflow/overflow)
 Reinitialize your pointers in mm_init

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 9

 Carnegie Mellon

Garbled Bytes
 Malloc library returns a block
 mdriver writes bytes into payload (using memcpy)
 mdriver will check that those bytes are still present
 If malloc library has overwritten any bytes, then report garbled bytes
 Also checks for other kinds of bugs

 Now what?

 The mm_checkheap call is catching it right?

 If not, we want to find the garbled address and watch it

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 10

 Carnegie Mellon

Garbled Bytes and gdb

 Get out a laptop

 Login to shark machine

 wget http://www.cs.cmu.edu/~213/activities/rec11b.tar
 tar xf rec11b.tar

 mm.c is a fake explicit list implementation.

 Source code is based on mm_baseline.c
 A few lines of code are added that vaguely resembles what an
explicit list implementation could have.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 11

 Carnegie Mellon

GDB Exercise
 gdb --args ./mdriver -c ./traces/syn-array-short.rep -D

(gdb) r
// Sample output follows
Throughput targets: min=6528, max=11750, benchmark=13056
Malloc size 9904 on address 0x800000010.
...
ERROR [trace ././traces/syn-array-short.rep, line 12]:
block 0 has 8 garbled bytes, starting at byte 0
...
Terminated with 2 errors
[Inferior 1 (process 13470) exited normally]
(gdb)

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 12

 Carnegie Mellon

GDB Exercise cont.

 What is the first address that was garbled?
 Use gdb watch to find out when / what garbled it.

(gdb) watch * 0x800000010

(gdb) run

// Keep continuing through the breaks:

// mm_init()
// 4 x memcpy We just broke in
Hardware watchpoint 1: *0x800000010 after overwriting

Old value = -7350814

New value = 0
mm_malloc (size=50084) at mm.c:272
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 13
 Carnegie Mellon

Second Exercise
Well fine, the bug from the first exercise was very artificial.
No one just sets bytes to 0 for no reason.
Try this more plausible exercise:

$ gdb --args ./mdriver-2 -c traces/syn-array-short.rep

What error was printed to the console?

The function that prints the error is named

malloc_error. Add a breakpoint for it if you want.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 14

 Carnegie Mellon

Second Exercise
The library must’ve written the header and footer for the
out-of-bounds payload at some point. Add a watchpoint for
either address, or both.

…So, the writes occurred in place. Is the place function

wrong, or was it just given a bad argument?

Hint: the bug is found in at basically the same place as last

recitation’s bug.
It’s caused by a careless typo, like nearly all others bugs.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 15

 Carnegie Mellon

Tips for using our tools

 Run mdriver with the –D option to detect garbled bytes as
early as possible. Run it with –V to find out which trace
caused the error.
 Note that sometimes, you get the error within the first
few allocations. If so, you could set a breakpoint for
mm_malloc / mm_free and step though every line.
 Print out local variables and convince yourself that they
have the right values.
 For mdriver-emulate, you can still read memory from the
simulated 64-bit address space using
mem_read(address, 8) instead of x /gx.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 16

 Carnegie Mellon

MallocLab
 Due Thursday

 8% of final grade (+ 4% for checkpoint)

 Read the writeup. It even has a list of tips on how to

improve memory utilization.

 Rubber duck method

 If you explain to a rubber duck / TA what your function does step-
by-step, while occasionally stopping to explain why you need each
of those steps, you’d may very well find the bug in the middle of
your explanation.
 Remember the “debug thought process” slide from Recitation 10?
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 17