How to track memory leaks with umdh.exe in all heaps?

Question

I have a c++ windows application that leaks memory per transaction. Using perfmon I can see the private bytes increase with every transaction, the memory usage is flat while the application is idle.

Following previous answers on stackoverflow I used umdh from the microsoft debugging tools to track down one memory leak. However there is still more leaks and the results of umdh don't match up with my perfmon results.

First umdh does still reports this leak, the stack trace is:

+   36192 ( 2082056 - 2045864)    251 allocs    BackTraceCB
+       4 (    251 -    247)    BackTraceCB allocations

    ntdll!RtlAllocateHeapSlowly+00000041
    ntdll!RtlAllocateHeap+00000E9F
    MSVCR80!malloc+0000007A

This is no use as the first call is malloc, it doesn't say what called it. I have my doubts about this leak as it is reported both when the application is processing transactions and when it is idle. But I can clearly see that no memory is leaking when it is idle. And the memory leaks reported when processing the transactions are not proportional to the transactions processed as perfmon reports.

umhd does not show any other leaks, although I know there is at least one more not shown. I have just learn from searching the net that a windows application can have multiple heaps.

• Could it be that umhd only reports memory usage from one of these heap? eg the default or crt heap?
• How can I track memory usage in other heaps?
• And how do find out what dlls / modules are using the other heaps?

Any pointers to tracking down this problem would be gratefully received as I am running out of options.

Answer 1

Unless your application (or the libraries it uses) explicitly creates its own heap(s), there is only one heap to worry about. Most libraries do not do this, so I would suggest this should not be your main avenue for investigation.

Answer 2

Maybe umdh is having trouble locating debug symbols for your code? That might explain why the stack trace is incomplete. Make sure you have built it with symbols and that they can be found.

Answer 3

I use to do a code review in search of memory leaks.

Some things I was looking for:

1. Inheritance problem: base classes that don't provide virtual destructor and are used polymorphically.
2. Search in the code for pointer declarations or pointer allocations (looked for * declarations, or keyword new, or malloc usage), and reviewed the pieces of code, targeting the lifecycle of the dynamically allocated objects.

Of course, code review can be time consuming, depending on the code base you have to review. But, if you can restrict the regions you need to look for pointer allocation/usage, it might payback. It did in most of my cases.

Answer 4

Sorry to answer my own question, but I finally tracked the issue down to how I used Orbix.

It seams that the orbix libraries use their own heap on the windows platform. This means that most memory leak detection does not work for leaks in orbix, I tried boundschecker and umhd.exe.

To isolate this issue I found some code that would dump the memory of each heap in the application: http://www.abstraction.net/content/articles/analyzing%20the%20heaps%20of%20a%20win32%20process.htm

I used this to dump the heap usage before and after each transaction, then after every 500 transactions, this indicated that the same heap was growing each time. Then I listed the the address of each entry in this heap. Examining the memory in these areas I found that these contained orbix marshalling data. With this information I finally found a some object references that were not being cleaned up.

Answer 5

For me, on occasions where umdh failed - another MS free tool called LeakDiag succeeded. It allows interception of far more allocator types than umdh, including what it calls a 'MPHeap allocator', which I suspect might have been of use to you. If you got a spare minute - I'm curious if that might have indeed helped..