3

The question Memory leak with java has been answered but is creating a memory leak possible in .net?

What would be an example?

Community
  • 1
  • 1

5 Answers5

0
for(int i = 0; i < 10; i++)
{
    IntPtr imageData = Marshal.AllocHGlobal(1024*1024);
}

This will result in 10 MB leaked memory for example. Everything unmanaged can leak, its hard to get something managed to leak memory, if at all.

SinisterMJ
  • 3,425
  • 2
  • 33
  • 53
  • 2
    I agree it is a memory leak, but I would strongly disagree that the memory leak is "in .NET" - the leak is in unmanaged area, and you've achieved it *via* .NET by explicitly moving **outside** of .NET – Marc Gravell Jun 29 '13 at 13:40
  • Well, basically the same as on Java would go as well, self-referencing objects will not be deleted. – SinisterMJ Jun 29 '13 at 15:30
  • self-referencing objects are an entirely different scenario, and neither Java nor .net would leak that. Since neither uses reference counting. – Marc Gravell Jun 29 '13 at 15:32
0

As far as I see, you can "leak" memory by creating a separate AppDomain each time a specific operation is executed and forget to unload that AppDomain after the operation is finished. At least, they don't seem to be unloaded automatically: http://nikcodes.com/2013/01/18/understanding-appdomain-unloads-old-lessons-learned-anew/

But one may argue this isn't a memory leak, because the AppDomains are stored internally and not "lost". However, I can't find a way to get all existing AppDomains and/or check if they are still in use to unload them. Plus, it can get quite nasty, depending on the size of Assemblies loaded into the AppDomain.

Edit: You can list all AppDomains, but it is technically not in .Net: List AppDomains in Process so if you argue Marshal.AllocHGlobal(1024*1024); is a memory leak but not in .Net, then "unreferenced" AppDomains are a memory leak because the solution is not in .Net.

; P

There are tons of philosophical discussions out there, whether unused references are to be called "resource leak" instead of "memory leak." For me, the AppDomain example might be a true memory leak, if there is no way of accessing the existing AppDomains.

Community
  • 1
  • 1
No answer
  • 907
  • 1
  • 9
  • 10
0

While not technically a leak, you can still observe the same symptoms (running out of memory) when you inadvertently keep references to objects you don't actually need any more. For instance if you have a static cache of previously computed data:

static List<string> previousResults = new List<string>();

public string GetSomeResult(int arg)
{
    string s = DoSomething(arg);
    previousResults.Add(s);
    return s;
}

Very stupid example, but it shows the point: When nobody ever clears the list, it will grow forever. I'm calling this a memory leak in .NET, even if it technically isn't one (as the objects are still addressable). There are more subtle ways of observing the same behavior where you don't see that you're still keeping references in the first place.

PMF
  • 14,535
  • 3
  • 23
  • 49
0

The most common memory leak I see in .NET is a static object that never goes away. This is common for Singleton objects, but it can also be a mistake from a misunderstanding of how static objects work.

Another, sneakier example of a memory leak is registering for a static event. For example, all of the events in the SystemEvents class are static. If an object registers itself for this event, it must de-register itself, or else the object will never be garbage collected.

We actually had that happen when someone registered a form to listen for the SystemEvents.SessionEnding event. These events are static. They hold on to a static list of delegates that are invoked when the event occurs. Even if the object is disposed, and all of your references to this object are set to null, the static event will continue to hold onto it, so the object will never be garbage collected. And since that object is preserved, all objects it references stay alive, too.

Paul Williams
  • 16,585
  • 5
  • 47
  • 82
0

Here's a good way to create a true memory leak (objects inaccessible by running code but still stored in memory) in pure Java:

The application creates a long-running thread (or use a thread pool to leak even faster).

The thread loads a class via an (optionally custom) ClassLoader.

The class allocates a large chunk of memory (e.g. new byte[1000000]), stores a strong reference to it in a static field, and then stores a reference to itself in a ThreadLocal. Allocating the extra memory is optional (leaking the Class instance is enough), but it will make the leak work that much faster.

The thread clears all references to the custom class or the ClassLoader it was loaded from. Repeat.

Credit: https://stackoverflow.com/a/6471947/6017500

AMRESH PANDEY
  • 195
  • 1
  • 10
  • I see little value in this answer, as there are **a ton** of ways to create memory leaks in .NET. Lifting much of the answer from a java answer (even though you posted the credit) also provides little value unless you rewrite it to be .NET-centric, and a class loader isn't particularly .NET-centric. Since you don't have class loaders in .NET I'm not entirely sure what your answer actually means in the context of .NET. "inaccessible to running code", does that include reflection? – Lasse V. Karlsen May 07 '18 at 13:42
  • And that really doesn't matter anyway, there's an easier way to create a memory leak in .NET. Simply add a static list and keep adding to it. A memory leak doesn't necessitate "inaccessible", it just means that the program is not releasing memory once it is done with it. If the memory is no longer needed, but some root is referring to it, that is by definition a memory leak, no need to circumvent the normal .NET memory manager to get one. – Lasse V. Karlsen May 07 '18 at 13:45