Develop Reference

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
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)

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
Take a snapshot
Repeat the leak procedure 10 times
Take a snapshot
Repeat the leak procedure another 10 times
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.

Cant detect memory leak with ANTS memory profiler

I have a custom application that allows to open some custom models.
If I open a model in the application, then open another model - memory isn't released from the first model.
When I try to profile memory leak with profiler (ANTS memory profiler), the application releases memory and I'm not able to track the leak. How can I manage this problem?

When you take a snap shot ANTS memory profiler does a full garbage collection.
When you want to take a snapshot, I normally take 2-3 snapshots until there is not memory differences between two consecutive snapshots. Then compare with your base snapshot.
Go to instance list and see if there is any instances are growing. Select the Objects with Source in order to get rid of heaps of system object.
If there is any growing instances, pick one and see the objects retention graph which will show you exactly which instance holds the reference.
And also, make sure that you have implemented IDisposable properly and dispose all disposable objects and unsubscribe from all event subscriptions.
Have a look at below walkthroughs
http://www.red-gate.com/products/dotnet-development/ants-memory-profiler/walkthrough http://www.red-gate.com/products/dotnet-development/ants-memory-profiler/

Are memory leaks possible in managed environments like .NET?

In C++ it is easily possible to have a permanent memory leak - just allocate memory and don't release it:
new char; //permanent memory leak guaranteed
and that memory stays allocated for the lifetime of the heap (usually the same as program runtime duration).
Is the same (a case that will lead to a specific unreferenced object never been released while memory management mechanisms are working properly) possible in a C# program?
I've carefully read this question and answers to it and it mentions some cases which lead to getting higher memory consumption than expected or IMO rather extreme cases like deadlocking the finalizer thread, but can a permanent leak be formed in a C# program with normally functioning memory management?

It depends on how you define a memory leak. In an unmanaged language, we typically think of a memory leak as a situation where memory has been allocated, and no references to it exist, so we are unable to free it.
That kind of leaks are pretty much impossible to create in .NET (unless you call out into unmanaged code, or unless there's a bug in the runtime).
However, you can get another "weaker" form of leaks: when a reference to the memory does exist (so it is still possible to find and reset the reference, allowing the GC to free the memory normally), but you thought it didn't, so you assumed the object being referenced would get GC'ed. That can easily lead to unbounded growth in memory consumption, as you're piling up references to objects that are no longer used, but which can't be garbage collected because they're still referenced somewhere in your app.
So what is typically considered a memory leak in .NET is simply a situation where you forgot that you have a reference to an object (for example because you failed to unsubscribe from an event). But the reference exists, and if you remember about it, you can clear it and the leak will go away.

You can write unmanaged code in .NET if you wish, you have enclose your block of code with unsafe keyword, so if you are writing unsafe code are you not back to the problem of managing memory by yourself and if not get a memory leak?

It's not exactly a memory leak, but if you're communicating with hardware drivers directly (i.e. not through a properly-written .net extension of a set of drivers) then it's fairly possible to put the hardware into a state where, although there may or may not be an actual memory leak in your code, you can no longer access the hardware without rebooting it or the PC...
Not sure if this is a useful answer to your question, but I felt it was worth mentioning.

GC usually delay the collection of unreachable memory to some later time when an analysis of the references show that the memory is unreachable. (In some restricted cases, the compiler may help the GC and warn it that a memory zone is unreachable when it become so.)
Depending on the GC algorithm, unreachable memory is detected as soon as a collection cycle is ran, or it may stay undetected for a certain number of collection cycles (generational GC show this behavior for instance). Some techniques even have blind spots which are never collected (use of reference counted pointer for instance) -- some deny them the name of GC algorithm, they are probably unsuitable in general purpose context.
Proving that a specific zone will be reclaimed will depend on the algorithm and on the memory allocation pattern. For simple algorithm like mark and sweep, it is easy to give a bound (says till the next collection cycle), for more complex algorithms the matter is more complex (under a scheme which use a dynamic number of generations, the conditions in which a full collection is done are not meaningful to someone not familiar with the detail of the algorithm and the precise heuristics used)

A simple answer is that classic memory leaks are impossible in GC environments, as classically a memory leak is leaked because, as an unreferenced block theres no way for the software to find it to clean it up.
On the other hand, a memory leak is any situation where the memory usage of a program has unbounded growth. This definition is useful when analyzing how software might fail when run as a service (where services are expected to run, perhaps for months at a time).
As such, any growable data structure that continues to hold onto references onto unneeded objects could cause service software to effectively fail because of address space exhaustion.

Easiest memory leak:
public static class StaticStuff
{
public static event Action SomeStaticEvent;
}
public class Listener
{
public Listener() {
StaticStuff.SomeStaticEvent+=DoSomething;
}
void DoSomething() {}
}
instances of Listener will never be collected.

If we define memory leak as a condition where a memory that can be used for creating objects, cannot be used or a memory that can be released does not then
Memory leaks can happen in:
Events in WPF where weak events need to be used. This especially can happens in Attached Properties.
Large objects
Large Object Heap Fragmentation
http://msdn.microsoft.com/en-us/magazine/cc534993.aspx

Memory Leaks C# [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I am trying to understand the concept of memory leaks better. Can anyone point up some useful information that can help me better understand exactly what memory leaks are and how I would find them in my code.

There are many kinds of memory leaks, but in general the term refer to some kind of resource that is no longer used, but still takes up memory. If you have many of those your application takes a lot of memory and eventually you run out of it.
In C#, these are some common memory leaks:
Not removing event listeners. Any event listener that is created with an anonymous method or lambda expression that references an outside object will keep those objects alive. Remember to remove event listeners when they are no longer used.
Keeping database connections or result sets open when they are not used. Remember to call Dispose() on all IDisposable objects. Use the using statement.
Call to C functions using p/Invoke which allocate memory which you then never release.

A traditional memory leak happens when you allocate memory, and then somehow "forget" to return or deallocate it. In old C++ code, this means calling new without a corresponding delete. In C, it meant a call to alloc()/malloc() without a corresponding free().
In .Net, you don't get memory leaks in the traditional sense, because you aren't supposed to release memory yourself. There is no equivalent to free() or delete you need to use. Even IDisposable and finalizers are not about memory. Instead, you rely on the garbage collector (GC) to release memory for you.
However, this doesn't mean you'll never lose track of memory. There are several ways you might accidentally keep a reference around that prevents the garbage collector from doing it's job. These include global variables (especially lists, dictionaries, and other collection types that might be used to "cache" objects), event handlers hanging on to an object reference, recursive history references, and the large object heap.
It's important to also note here a pattern of increasing memory use in .Net doesn't necessarily mean your app is leaking memory. In cases of low overall memory pressure the garbage collector could instead be opting to save time by not collecting yet, or by collecting within the process's existing address space only without returning the memory to the operating system.

A very good read is Everybody thinks about garbage collection the wrong way.
In general, a memory leak, or any resource leak, is whenever the program allocates memory (or any other resource) and then omits to deallocate it when finished with it. In native application memory leak is the most common resource leak and can happen when the resource reference (the pointer to the allocated block) goes out of scope and is destroyed, but allocated resource (the memory block) does not get destroyed. In this case the resource (memory) is leaked because the program has lost the ability to release it, even if it wants to, because it no longer remembers the location of the resource (the address of the block).
In managed applications memory leaks are a bit trickier. Since the runtime can track references to resources automatically, it can also understand when a resource (an object) is no longer referenced by any active part of the application (there is no chain of references from a stack frame to that resource on any thread) and thus the runtime can understand when is safe to collect the objects no longer references by the application. So in managed world a a 'leak' would occur when you believe that the applicaiton no longer references an object (and thus it can be collected by the runtime) but in fact, through some chain of references, you do have a reference to it and thus it cannot be collected.
I highly recommend Raymond Chen's article linked above, is very very illuminating.

When memory is assignned to an application, the application has an obligation to release that memory back to the operating system so that it can be re-used by other applications. A memory leak occurs when an application does not release that memory, thus preventing it from being reallocated.
For managed code, the garbage collector tracks references to the objects created by an application. For most situations the CLR will handle memory allocation and deallocation transparently and in a reasonable way on behalf of the running process. However .NET developers still need to consider resource management as there are still situations in which memory can leak despite the work of the garbage collector.
Consider the following code:
Widget widget = new Widget();
The above line of code creates a new instance of the Widget class and the widget field is assigned a reference to that object. GC keeps track of the references associated with each object and deallocates the memory of objects for which there are no strong references.
It's worth mentioning that the CLR's garbage collection will only collect managed objects, .NET code can and does frequently make use of unmanaged resources which can not be garbage collected automatically.
Unmanaged resource leaks occur when the object for which those resources were allocated fails to correctly deallocate them before the last reference to those resources goes out of scope, which leaves the resources allocated, but unreferenced and therefore unusable to the application.
Classes which reference unmanaged resources directly should ensure that those resources are correctly deallocated. An example of doing this would look something like this:
public void ManagedObject : IDisposable
{
//A handle to some native resource.
int* handle;
public ManagedObject()
{
//AllocateHandle is a native method called via P/Invoke.
handle = AllocateHandle();
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
private void Dispose(bool disposing)
{
if (disposing)
{
//deal with managed resources here
FreeHandle(handle);
}
}
~ManagedType()
{
Dispose(false);
}
}
The disposing parameter is false when being called from a finalizer. This is to prevent managed resources being used from within the finalizer as managed references should be considered invalid at that stage.
Note also that the Dispose() method calls GC.SuppressFinalize(this) which prevents the finalizer running for that instance. This is done because the resources that would have been deallocated in the finalizer were deallocated in the Dispose call making a fializer invocation unnecessary.
Client code that makes use of classes that handle unmanaged resources (or any class that implements IDisposable) should do so within a using block to ensure that the IDisposable.Dispose is called when access to the resource is no longer needed as this will take care of both managed and unmanaged resources and, in the case of the example above, ensure that a very expensive call to the finalizer is not made.
Appoligies for my rambling. I'll stop now.

A memory leak occurs when your program dynamically allocates memory that doesn't get properly deallocated after you're done using it. If you have a program that continuously does this, your leak will get bigger and bigger and pretty soon your program is taking up all your RAM.

"Memory leak" should be defined as "memory that is used when YOU believe it should not be used" to apply to garbage collected languages/runtimes as C#/Java.
Traditionally "memory leak" is defined as memory that is not properly deallocated (see wikipedia link in other answers) which generally does not happen for garbage collected environments. Note that due to problems with runtime even garbage collected languages can leak memory - i.e. even if JavaScript is garbage collected language, it was easy to leak large amount of JavaScript objects in Internet Explorer's JavaScript runtime.

What is the difference between C++ memory management and .NET memory management?

What is the difference between C++ memory management and .NET memory management ?

In C++, you can either allocate objects with static storage so they are around for the whole program, allocate them on the stack when they are local to a function (in which case they are destroyed when the containing block exits), or allocate them on the heap (in which case they are only destroyed when you say so by explicitly calling the appropriate de-allocation function). Heap memory is allocated as raw memory with malloc and released with free, or allocated and constructed into an object with new, and then the object destroyed and the memory released with delete.
C# provides an illusion of infinite memory --- you cannot free memory explicitly, only allocate memory and construct an object with new. Instead the GC reclaims the memory for objects you can no longer access so that it can be reused for new objects.
In C++, class destructors are run when an object is destroyed. This gives each object a chance to release any associated resources whether they are more objects, or external resources such as file handles or database handles.
In C#, you must explicitly manage the release of non-memory resources by calling a release function. The using facility allows you to get the compiler to call Dispose() automatically for you, but this is still separate from the object lifetime --- the memory for the object is reclaimed when the GC system decides to (which may be never).
In C++, facilities like std::shared_ptr (or boost::shared_ptr with older compilers) allow you to pass the responsibility of destroying heap objects over to the C++ runtime by reference-counting the objects. When the last instance of shared_ptr that references a given object is destroyed, then the referenced object is destroyed too and its memory reclaimed. This avoids many of the pitfalls associated with manual memory management.

In .NET, memory is treated different than all other resources: While you have to take care of releasing all resources you need, you don't have to worry about memory.
In C++, you have to take care to release all resources you use, including dynamically allocated memory. However, C++ employs a number of tools and techniques (namely automatic scope-based allocation/deallocation and RAII) to help you with this. In a decade of writing C++ code, I have rarely ever (read: on average less than once per year) manually freed memory and if so, it was in a RAII handle class.

In C#, there is a whole lot less to worry about.
When you want to work with an object in C#, you can simply create it; and once you're done with it, you don't have to do anything else. A background worker (the Garbage Collector) will clean it up behind the scenes when it realises you're not using it any more.
In vanilla C++, there aren't any background processes running to clean up memory. This means that, any time you manually allocate memory (which is a lot of the time), you are responsible for deleting it once you're finished using it. Care must also be taken to ensure you don't delete the same thing twice.
A note on the C# side of things: This doesn't mean you can completely ignore how memory works. It's very helpful to know what happens behind the scenes. In general, though, you won't have to worry about it much.
Edit: As GMan notes below (if I'm understanding him correctly), you can deal with memory management in C++ by letting every allocation be scoped, and thus the C++ environment will look after allocation and deletion for you. In that sense, you again have to understand how C++ allocates and deletes in order to not run into troubles.

some c++ open source choosed to create their own memory gabrage collector like V8 javascript engine to avoid all problems of memory leaks.