CODEWITHSUNDEEP
clinuxdebuggingmemory-leaks
tay10r
tay10r

Reputation: 4337

Implementing a Memory Debugger

I've written a debugger using ptrace(2) that is mainly for auditing system calls and redirecting standard IO of a child process. I would also like to detect memory leaks using this debugger.

I thought that it might be as easy as counting references to the system call brk(2), but it isn't. Unfortunately (or fortunately), Linux seems to call brk(2) at the end of the program regardless of whether or not the memory was properly freed.

I've seen this in a program that calls malloc(3) and free(3) and a program that just calls malloc(3) - they both have equal counts of brk(2) calls by the time the program has called exit_group(2), which is happens on return (perhaps I could be interpreting those results incorrectly?).

Or, perhaps exit_group(2) isn't equivalent to 'return' from main, and I should be setting a different break point for auditing the call count of brk(2).

I found a similar question here, but I still haven't found an answer.

I understand that Valgrind is a perfect tool for this, but it would cause considerable overhead.

Does anyone have helpful information on detecting memory leaks with ptrace(2)? Is possible with ptrace(2)? Is there a more practical way? Is there an API for memory debugging child processes?

Edit:

If there's other functions involved with allocate memory, I would count those too. On the page for malloc, it says that mmap(2) is also used in memory allocation. So, I would be counting that too.

Upvotes: 2

Views: 165

Answers (1)

KrisSodroski
KrisSodroski

Reputation: 2842

Use gdb's heap extension. It will do what you want. IF you want to use it programatically, just pipe the results to your application to do post processing:

https://fedorahosted.org/gdb-heap/

Upvotes: 1

Related Questions