CODEWITHSUNDEEP
c#.netmemory-leaksgarbage-collectionunmanaged
BendEg
BendEg

Reputation: 21088

Memory leak because of pinned GC handles / no gc root visible

What is the reason for pinned GC handles when working with unmanaged .net components? This happens from time to time without any code changed or something else. When investigating the issue, I see a lot of pinned GC-Handles

GC-Handles

These handles seem to stick in the memory for the entire application lifetime. In this case, the library is GdPicture (14). Is there any way to investigate why those instances are not cleaned up? I'm using Dispose()/using everywhere and can't find any GC roots in the managed code.

Thanks a lot!

EDIT

Another behaviour that is strange is, that the task manager shows that the application uses about 6GB ram, when the memory profiler shows the usage of 400MB (red line is live bytes)

Live bytes

Upvotes: 1

Views: 974

Answers (1)

Thomas Weller
Thomas Weller

Reputation: 59279

What is the reason for pinned GC handles when working with unmanaged .net components?

Pinning is needed when working with unmanaged code. It prevents objects from being moved during garbage collection so that the unmanaged code can have a pointer to it. The garbage collector will update all .NET references, but it will not update unmanaged pointer values.

Is there any way to investigate why those instances are not cleaned up?

No. The reason always is: there's a bug in the code. Either your code (assume that first) or in a 3rd party library (libraries are used often, chances are that leaks in the library have been found by someone else before).

I'm using Dispose()/using everywhere

Seems like you missed one or it's not using the disposable pattern.

Another behaviour that is strange is, that the task manager shows that the application uses about 6GB ram, when the memory profiler shows the usage of 400MB (red line is live bytes)

A .NET memory profiler may only show the .NET part of memory (400 MB) and omit the rest (5600 MB).

Task manager is not interested in .NET. It cares about physical RAM mostly, which is why Task Manager is not a good analytics tool in general. You don't want to analyze physical RAM, you want to analyze virtual memory.

To look for memory leaks, use Process Explorer and show the "Private Bytes" and "Virtual size" column. Process Explorer can also show you a graph over time per process.

How to proceed?

Forget about the unmanaged leak for a moment. Use a .NET profiler that has the capability of taking memory snapshots and allows you to see each individual object inside as well as a statistics.

Try to figure out the steps that it takes to create more leaks in a consistent way. Then

  1. Take a snapshot
  2. Repeat the leak procedure 10 times
  3. Take a snapshot
  4. Repeat the leak procedure another 10 times
  5. Take a snaphot

Compare snapshot of step 1 and 3. Check for managed types that differ in multiples of 10. Compare snapshot of step 3 and 5. Check the same type again. It must be a multiple of 10. You can't leak 7 objects when you run a method 10 times.

Do a code review on the places where the affected types are used based on internal knowledge on the leak procedure (which methods are called) and the managed type. Make sure it's disposed or released properly.

Upvotes: 4

Related Questions