YAHMD - Yet Another Heap Memory Debugger Debapriyay Mukhopadhyay IXIA Technologies Pvt Ltd, Kolkata Subhas C. Nandy Indian Statistical Institute, Kolkata

Motivation According to NIST, software bugs cost the U.S. economy an estimated 59.5 billion dollar annually and memory-related bugs are the most difficult ones to catch of all software bugs, particularly in the programs written in C or C++ language. In complex embedded products, in every release, quality engineers use to come across quite a good number of bugs, which are related to oom, memory leak, memory over-run, memory under-run, double free, stack smashing, etc. Typically these bugs take a lot of time to get to the root cause and to fix it.

Motivation Valgrind, Asdfalloc, Purify, Diduce – there are tools to isolate these problems. But, These tools provide us with a huge amount of information and it is really a pain to get to the origin of the problem. These tools can not be applied selectively module wise. They are not very good to detect memory corruption. These tools can not be applied to debug kernel modules. Many of these tools require the code base to be built in debug mode – the Bug may not reproduce when built in debug mode.

What we aim? We aim to come up with a debugger framework which the existing tools is not supportive of doing. We want the debugger framework to be lightweight with a very low memory foot-prints. We also want our framework capable of isolating the following memory related bugs. Buffer overflow: Illegal access beyond the buffer boundary. This includes both memory overrun and underrun. Memory Leak: Dynamically allocated memory having no reference to it, hence is never freed. OOM: Out Of Memory issues because of either memory leak, or inappropriate design/implementation. Double Free: One memory location is freed twice. Uninitialized Read: Read memory data before it in initialized. K to

Code Instrumentation Many of the existing tools use this approach of source code instrumentation. We also use this approach. We have tried to formalize the problem of code instrumentation against the design of the framework. And this unified approach was missing in earlier works. YAHMD identifies the allocated heap variables with the virtual memory addresses as returned by malloc, alloc, calloc, realloc etc. It remains same across the functions - only the name with which we refer this addess in a program changes. Since YAHMD directly deal with these addresses, no special handling required to detect memory related issues across functions, different paths, contexts, etc. YAHMD does dynamic analysis of the code to look for errors.

High-Level Design of the Framework

Example Usages of the Macro

A Few More The Macros YAHMD_CHECK_MEMORY_PROBLEMS and YAHMD_UPDATE_SYM_TABLE are used in pairs for the following two cases Assignment statements which assigns value to a pointer variable and these Macros are used immediately before the statement. Statements involving only pointer arithmetic and these Macros in pairs are also used before these type of statements.

Results

Conclusion YAHMD framework identifies the allocated variables with the virtual memory addresses, so it is easy for the framework to isolate memory issues even across multiple functions. The framework assumes as if it is allocating or deallocating memory from memory pool and keeps track of the necessary information. But the framework actually does not intercept the memory allocation / deallocation calls. This method, what we call virtual execution of memory related instructions, is used in YAHMD. But, actually there is no memory pool, YAHMD mimics/simulates the behavior as if we are interacting with a pool based memory management system. The memory used by YAHMD framework is proportional to the number of heap variables used in the program – footprint is low. YAHMD framework can be easily extended to kernel modules.

Future Research Directions To come up with a solution to plug in the framework into any code-base without any manual intervention. What could be the optimal value for the size of each Memory Pool? To come up with metrics to evaluate the performance of the debugger framework. How to extend the framework to detect Stack Smashing and Assertion Violations. Whether this framework can be extended to detect memory problems related to static allocations. Can this framework be extended to identify the program execution sequence in which the problem occurred and has been detected. Can this framework be used to detect vulnerabilities in C/C++ code.

Questions?