Issue with unmanaged memory

kenwbrand

Hello All,

I'm trying to find the cause of a memory leak that causes my program's unmanaged memory to increase.

I've started by first taking a memory snapshot when the program starts. I took a second snapshot after 30 min or so of runtime and then compare the snapshots.

What I'm seeing is an increase of just over 7 MB of unmanaged memory between the two snapshots, However; when I look at the individual unmanaged dlls I only calculate a 2 MB increase. It also seems that over 800 KB of that is an increase in the redgate profiling dll.

My question is where is the missing 5 MB of memory being used? How can I solve this problem?

Jessica R

Hi and thanks for your post!

Regarding your query, the profiler results will normally show an unmanaged memory summary that is greater than the total of unmanaged memory breakdown because the breakdown does not include the memory used by the stack (the stack memory usage usually increases when the number of threads increase).

Just some more detailed information on the difference: the information in the pie chart is obtained by analyzing the application's entire virtual memory usage when the snapshot is taken using Windows APIs, and so it should include everything, including the stack. The breakdown on the right is based on our detection of memory allocations and attempts to allocate them to a particular module which was on the stack at the time. It should contain most allocations on the heap and allocations of pages of virtual memory requested by the application (excluding heap allocations before the profiler started, or commits of virtual memory pages reserved before the profiler started), but doesn't necessarily take into account things such as the stack.

Eventually, we want to show information about the stack usage in the module breakdown so that when the breakdown values are added up, they do total up to the same pie chart value, though this may not be in the immediate future, I'm afraid. For now, the pie is the most complete and accurate overview of unmanaged memory usage. However, the unmanaged breakdown can still help to identify if for example, a certain module's code is requesting large blocks of unmanaged memory and neglecting to free it again.

I hope this information helps clarify things and so sorry for any troubles and confusion caused!

kenwbrand

So this tells me that the memory leak is in the stack then. I already tracked the number of threads and handles the program had using the task manager. This doesn't seem to be increasing over time however. Is there anyway to utilize the profiler to find a stack memory issue?

-Ken

Jessica R

Hi Ken,

I'm afraid the profiler can't provide more details about the stack memory usage. You may find windbg useful though as you can use ~*k to dump call stacks for all threads, or use it to inspect some of the handles to find out what they are (as described here: http://blogs.technet.com/b/yongrhee/arc ... -leak.aspx)

I hope that might be of some help!