Help interpreting unmanaged memory size reporting

sgorozco

Hi,
Could someone explain me what I'm interpreting wrong? I am seeing what seems to be an unamaged memory leak in our code. The summary window shows the Allocated by managed code counter steadily climbing between snapshots. (e.g. a 1-minute gap between snapshots, shows a positive difference of ~20-40KB).  However, when I go to the managed class list and order the results by Unmanaged Size, only a few class types are holding to unmanaged memory and their combined size does not add up to the total reported on the Summary Window, futhermore, their reported consumption sizes do not vary between snapshots. I have no class filter applied. 

The solution does make use of several C++/CLI modules. Could that be the problem?

Jessica R

Hi @sgorozco,

Thanks for your post!

The value for unmanaged memory "Allocated by managed code" accounts for the memory allocated directly by managed code via MarshalAllocHGlobal or similar methods.

When you take a look at the class list, you can see how much unmanaged memory each managed class references via the "Unmanaged size" column. In theory, all the values under the "Unmanaged size" column should add up to the "Allocated by managed code" value in the breakdown. However, the profiler can't always associate unmanaged memory with the classes that referenced it, so the column values can often add up to less.

The reason for this: the profiler calculates the size of unmanaged memory associated with a .NET object (the value shown in the "unmanaged size" column) by checking the object for IntPtrs that are associated with particular unmanaged allocations. However, it can't always associate unmanaged memory with instances that reference it. One example is if the IntPtr to unmanaged memory is contained within a struct.

With that, are you able to do a search through your code and its dependencies to check for calls to "intptr" or "MarshalAlloc"?

sgorozco

Hi Jessica, thank you very much for your response. Yes, IntPtr is used heavily throughout the codebase, especially when "marshaling" pointers to native classes through managed interfaces. I still have not tracked the source of the leak but at least I know why the values don't add up. Cheers!

Jessica R

No worries, @sgorozco, glad that info helps clarify things!