Debugging Dynamic Memory

Prof. Brian D. Davison

Computer Science & Engineering, Lehigh University

Announcements

• I've posted a one page GDB reference card (PDF)
• New project #4 (debugging) not online yet, expected to be due Thursday
• Today's schedule
  • Collect homework #3
  • Short Quiz 5: Preprocessor+Debugging
  • Return project #3 -- range 78-100, mean 94
  • Discuss dynamic memory-checking

Dynamic Memory Checking

• Wednesday's debugging showed how to use
• Debugging printf() statements
• gdb and ddd debuggers
• Both are excellent tools when a program dies on the line where the error is found
• Problems with dynamic memory management, however, can lead to errors that only manifest themselves much later, in an error-free section of code
• Fortunately, there are other debugging tools that can help with dynamic memory checking

Which errors to check?

• There are many errors we might want to capture!
• Read before allocating memory
• Write before allocating memory
• Read before beginning of allocated space
• Write before beginning of allocated space
• Read after end of allocated space
• Write after end of allocated space
• Read after deallocating memory
• Write after deallocating memory
• Failure to deallocate memory
• Deallocating memory twice
• Deallocating nonallocated memory
• Zero-size memory allocation

Dynamic Memory Checking Capabilities

• There are a variety of dynamic memory checking tools today, each with different capabilities.
• Some malloc libraries (such as GNU libc used in Linux) have debugging facilities (e.g., malloc checking, mtrace).
• Some tools require re-compilation; many do not (dynamic library linking or other methods).

Dynamic Memory Checking Tools

• ccmalloc. Finds memory leaks and pointer access to freed data.
• Electric Fence (Linux man page). Electric Fence helps you detect two common programming bugs: software that overruns the boundaries of a malloc() memory allocation, and software that touches a memory allocation that has been released by free(). Unlike other malloc() debuggers, Electric Fence will detect read accesses as well as writes, and it will pinpoint the exact instruction that causes an error. Can operate with static or dynamic linking.
  
  Electric Fence uses the virtual memory hardware of your computer to place an inaccessible memory page immediately after (or before, at the user’s option) each memory allocation. When software reads or writes this inaccessible page, the hardware issues a segmentation fault, stopping the program at the offending instruction. In a similar manner, memory that has been released by free() is made inaccessible, and any code that touches it will get a segmentation fault.

Dynamic Memory Checking Tools

• Valgrind - open source memory debugger. Valgrind is a flexible system for debugging and profiling Linux-x86 executables. The system consists of a core, which provides a synthetic x86 CPU in software, and a series of tools, each of which performs some kind of debugging, profiling, or similar task.
• MEMWATCH. A memory leak detection tool.
  • Detects double-free()s and erroneous free()s
  • Detects unfreed memory
  • Detects overflow and underflow to memory buffers
  • Can set max allowed memory to allocate, to stress-test app
  • Can detect wild pointer writes
• MemCheckDeluxe. MemCheckDeluxe is a memory tracking program that allows one to find where programs and libraries leak memory. It also tracks the largest and smallest allocations, as well as the program's maximum memory usage.

Dynamic Memory Checking Tools

• mpatrol. Attempts to diagnose run-time errors that are caused by the wrong use of dynamically allocated memory. No recompilation for dynamically linked applications.
• Watchmalloc. Sun replacement library for malloc. No recompilation for dynamically linked applications (env LD_PRELOAD=watchmalloc.so.1 <app-name>).
• dbx is the Berkeley UNIX symbolic debugger. In addition to usual debugging facilities, dbx can also show memory leaks. -g is helpful, but no recompilation needed. Often available for Solaris.
• MemProf. Tool for profiling memory usage and finding memory leaks. It can generate a profile how much memory was allocated by each function in your program. It can scan memory and find blocks that you've allocated but are no longer referenced anywhere. Easy-to-use GUI. Usually available on Linux.

Dynamic Memory Checking Tools

• IBM Rational Purify. Well-known commercial tool that detects memory corruption and memory leaks. Does not require compilation (so it can be used with third party libraries). Windows and UNIX/Linux versions.
• Checker is a tool which finds memory errors at runtime. Its primary function is to emit a warning when the program reads an uninitialized variable or memory area, or when the program accesses an unallocated memory area. Checker issues warnings when:
  • free or realloc is called with a pointer that has not been obtained from malloc, calloc, or realloc.
  • free or realloc is called with a pointer that has been previously freed.
  Checker will also display all memory leaks along with the functions that called malloc.

Code checking walk-through

• Let's test two of these packages: ccmalloc and Electric Fence as they have different capabilities:
• -- EF Read before beginning of allocated space
• CC EF Write before beginning of allocated space
• -- EF Read after end of allocated space
• CC EF Write after end of allocated space
• -- EF Read after deallocating memory
• -- EF Write after deallocating memory
• CC -- Failure to deallocate memory
• CC EF Deallocating memory twice
• CC -- Deallocating nonallocated memory
• CC EF Zero-size memory allocation

Test code

• We will use two programs to demonstrate these tools. The first is a simple program with a leak, called leak.c. The second lets us test allocation, access, deallocation, etc., dynamically, called malloc-use.c.
• leak.c has two sources of leaks.
• malloc-use.c can have a variety of problems, chosen at runtime.
• We should also examine the Makefile to see how we build variations of these executables.
• Should now open two shells (one for editing, one for executing).

Testing with ccmalloc

• We have generated ccmalloc-based executables for both test programs.
• For leak-cc, it will find the double-deallocation, and the two leaks.
• For malloc-use, we can find leaks, using the commands:

  io:~/memtest% ./malloc-test-cc 10
  Please enter a command: a 0 10  
  Please enter a command: q
  

  a i b allocates b bytes for array entry i. d i will deallocate memory at entry i. r i p will read the pth character from array i. w i p will write to the pth character in array i. q quits.

Testing with ccmalloc

• It can also find double de-allocation with:

  io:~/memtest% ./malloc-test-cc 10
  Please enter a command: a 0 10  
  Please enter a command: d 0 
  Please enter a command: d 0 
  

  and reads of unallocated data

  io:~/memtest% ./malloc-test-cc 10
  Please enter a command: r 1 1
  

  but not reads/writes after deallocation

  io:~/memtest% ./malloc-test-cc 10
  Please enter a command: a 0 10
  Please enter a command: d 0 10
  Please enter a command: r 0 1
  

Testing with Electric Fence

• For leak-ef, it will find the double deallocation, but not the leaks.
• For malloc-use, it does not find leaks

io:~/memtest% ./malloc-test-ef 10
Please enter a command: a 0 10  
Please enter a command: q

but it can find double deallocations and reads/writes after end of allocation and after deallocation

io:~/memtest% ./malloc-test-ef 10
Please enter a command: a 0 10  
Please enter a command: r 0 10
Please enter a command: d 0
Please enter a command: d 0
Please enter a command: r 0 1

• EF by default checks only for writing beyond the end of allocated space; we can change that through an environment variable:

  io:~/memtest% export EF_PROTECT_BELOW=1
  io:~/memtest% ./malloc-test-ef 10
  Please enter a command: a 0 10  
  Please enter a command: r 0 -1
  

Conclusions

• No one tool is sufficient.
• There are plenty of useful tools -- no excuses for bad memory management!