I've implemented Dispose...everywhere that supports it. I am removing all event handlers. I'm not calling native code.
I even iterate through every dictionary and set the values to null and call .Clear() on all the items.
Question:
How can I figure out where my code is leaking?
I first discovered the leak by running it in test overnight. It uses a fixed amount of memory so it should grow and then become somewhat static. I then made the foreground thread display memory like this:
if (key.KeyChar == 'g')
{
long pre = GC.GetTotalMemory(false);
long post = GC.GetTotalMemory(true);
Console.WriteLine("{2} Pre:{0} \tPost:{1}", pre, post, System.DateTime.Now);
GC.Collect();
}
I ran this several times (over several hours, pressing "g" once in a while) and saw an ever-increasing number.
The best way to track this down is to use a memory profiler...There are lots to choose from.
.NET Memory Profiling Tools
Make sure you use
try
{
}
finally
{
youDisposableObject.Dispose();
}
or
using (yourDisposableObject) {}
to every object you implemented "Dispose"
if you implemented finalizers to some of the objects without any need, remove them
if you still can't fix it after that, you will have to use a memory profiler
There's an article that describes how to do it using SOS.dll here and a more comprehensive one here.
Depending on the version of Visual Studio you're using (Premium or Ultimate), you can also use the normal Code Analysis tools to help find issues in your code that can lead to memory leaks. (Details here)
Of course, in managed code, memory leaks are a bit different than they are in unmanaged code. In unmanaged code, where you allocate and deallocate memory explicity, memory leaks are caused by failing to deallocate the memory.
In .NET, a memory leak comes from hanging onto an object longer than intended. This can largely be avoided simply by following best practices of using the using statement where possible, and by carefully planning the scope of your variables.
I just had the same problem in my c# application and used (actually the trial Version) of
dotTrace memory profiler which was very helpful.
It still took some time to localize the actual lines of code where the leak occurred. So do not expect that tool to immediately identify the culprit right away.
Issue : What is the best way to have a comprehensive view of birth/death/mem usage of ALL objects created during an application lifetime? (graphic report would be better)
Why such a question :
Among many others, the idea behind that, is to reveal long-living objects that may never be collected by the garbage collector or cause memory trouble (such as heap/stack issues or so), and provide valuable information to efficiently manage object lifecycles (I actually just spent a whole night debugging a multithreaded application to finally notice that a "believed to be disposed/renewed" object was in fact still alive and smashing up the server memory.)
VS2010 Performance Wizard & Profiler might be a good starter...
I stumbled upon few ways to do this programmatically but it involved wrapping up objects individually (painstaking and not code-seamless)
I'm looking for something that would look like this :
Application START[-----------------------------------------------------------]END
Object 1 [---------------------------]
Object 2 [---------------------------]
Object 3 [-----------------------------------------------------]
Mika,
As you noted you can use the VS2010 Profiler (if you have Visual Studio Premium or Ultimate). For more information see the MSDN page about collecting 'Object Lifetime' information.
Beware that this profiling mode is pretty heavyweight compared to other profiling modes and you may find the collected VSP file is quite large unless you have a fairly focussed scenario that you are profiling.
The profiling report will show the information in tabular form, but you can copy the data into Excel or another program of your choice for further analysis/charting.
Disclaimer: I work on the Visual Studio profiler.
There are some tools which can do that but not as easily as graph. You will need to learn a bit on those tools.
Free:
CLR Profiler
http://msdn.microsoft.com/en-us/library/ff650691.aspx
WinDbg:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Use the SOS or SOSEX extension with Windbg to profile .NET code.
Commercial :
Red Gate Ants Profiler:
http://www.red-gate.com/products/dotnet-development/ants-performance-profiler/
The app I am writing is suffering quite dramatically from a memory leak. Pretty much the entire object model is staying in memory when a user closes down a loaded project. The way I know this is because closing a project in my app barely effects the memory usage in the task manager and then opening a new project almost makes it double each time. I downloaded jetBrain's dotTrace Memory 3.5 but there is little (none) instructions for use. I kinda figured out how to use it and it shows that the whole object model is still in memory when i take a snapshot after a project has been closed down. Trawling through my projectClose code I can see no reason for this. Does anyone know of anything in particular that normally causes memory leaks in C# or of any tools or techniques for tracking down the problem. Its all well and good having an app that shows my entire object model is still loaded into memory but it doesnt show me what object or variable is storing it. Thanks in advance.
Firstly, investigate whether the leak could be due to registration of event handlers as this is one of the easiest ways to accidentally root your objects. For example, if you have a class 'Bob' that adds one of its methods 'OnSomeEvent' as a delegate to an event that is raised by a long-living component of your system (e.g. 'UserSettingsManager') then objects of class 'Bob' will not be collected as they are kept alive by virtue of being an event handler (i.e. event callbacks are not weak references).
As an alternative to the commercial tools, there is an extension to the Windows debugger called SoS (Son of Strike) that you can use to debug managed applications. However, it is not the faint-hearted as it is a low-level, command-line tool that requires a lot of up-front learning. It is very powerful, however, and does not struggle so much with larger processes (in terms of heap consumption) as the commercial tools do.
In terms of the commercial profilers, I've had good experiences with Redgate's ANTS Memory Profiler (but I have had colleagues who hate it) so it may be worth trialing that.
Probably the most common cause of managed memory leaks is unsubscribed event handlers.
There are a number of useful tools for tracking errors like this. Personally I like ANTS Memory Profiler and WinDbg/SOS. You want to find out what is rooting the object graphs. With WinDbg/SOS there's a !gcroot command, that will tell you the roots of any given object.
Check Tess' blog for guides on how to troubleshoot memory problems using WinDbg/SOS.
try these:
http://blogs.msdn.com/b/tess/archive/2010/01/14/debugging-native-memory-leaks-with-debug-diag-1-1.aspx
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en
I have written various C# console based applications, some of them long running some not, which can over time have a large memory foot print. When looking at the windows perofrmance monitor via the task manager, the same question keeps cropping up in my mind; how do I get a break down of the number objects by type that are contributing to this footprint; and which of those are f-reachable and those which aren't and hence can be collected. On numerous occasions I've performed a code inspection to ensure that I am not unnecessarily holding on objects longer than required and disposing of objects with the using construct. I have also recently looked at employing the CG.Collect method when I have released a large number of objects (for example held in a collection which has just been cleared). However, I am not so sure that this made that much difference, so I threw that code away.
I am guessing that there are tools in sysinternals suite than can help to resolve these memory type quiestions but I am not sure which and how to use them. The alternative would be to pay for a third party profiling tool such as JetBrains dotTrace; but I need to make sure that I've explored the free options first before going cap in hand to my manager.
There is the CLR Profiler that lets you review various object graphs (I've never used it):
http://www.microsoft.com/downloads/details.aspx?FamilyID=86ce6052-d7f4-4aeb-9b7a-94635beebdda&displaylang=en
Of course, ANTS Profiler (free trial) is an often recommended profiler. You shouldn't need to manually garbage collect, the GC is a very intelligently built solution that will likely be more optimal than any manual calls you do. A better approach is to be minimalist with the number of objects you keep in memory - and be rid of memory-heavy objects as soon as possible if memory is priority.
My program, alas, has a memory leak somewhere, but I'll be damned if I know what it is.
Its job is to read in a bunch of ~2MB files, do some parsing and string replacement, then output them in various formats. Naturally, this means a lot of strings, and so doing memory tracing shows that I have a lot of strings, which is exactly what I'd expect. The structure of the program is a series of classes (each in their own thread, because I'm an idiot) that acts on an object that represents each file in memory. (Each object has an input queue that uses a lock on both ends. While this means I get to run this simple processing in parallel, it also means I have multiple 2MB objects sitting in memory.) Each object's structure is defined by a schema object.
My processing classes raise events when they've done their processing and pass a reference to the large object that holds all my strings to add it to the next processing object's queue. Replacing the event with a function call to add to the queue does not stop the leak. One of the output formats requires me to use an unmanaged object. Implementing Dispose() on the class does not stop the leak. I've replaced all the references to the schema object with an index name. No dice. I got no idea what's causing it, and no idea where to look. The memory trace doesn't help because all I see are a bunch of strings being created, and I don't see where the references are sticking in memory.
We're pretty much going to give up and roll back at this point, but I have a pathological need to know exactly how I messed this up. I know Stack Overflow can't exactly comb my code, but what strategies can you suggest for tracking this leak down? I'm probably going to do this in my own time, so any approach is viable.
One technique I would try is to systematically reduce the amount of code you need to demonstrate the problem without making the problem go away. This is informally known as "divide and conquer" and is a powerful debugging technique. Once you have a small example that demonstrates the same problem, it will be much easier for you to understand. Perhaps the memory problem will become clearer at that point.
There is only one person who can help you. That person's name is Tess Ferrandez. (hushed silence)
But seriously. read her blog (the first article is pretty pertinent). Seeing how she debugs this stuff will give you a lot of deep insight into knowing what's going on with your problem.
I like the CLR Profiler from Microsoft. It provides some great tools for visualizing the managed heap and tracking down leaks.
I use the dotTrace profiler for tracking down memory leaks. It's a lot more deterministic than methodological trial and error and turns up results a lot faster.
For any actions that the system performs, I take a snapshot then run a few iterations of the function, then take another snapshot. Comparing the two will show you all the objects that were created in between but were not freed. You can then see the stack frame at the point of their creation, and therefore work out what instances are not being freed.
Get this: http://www.red-gate.com/Products/ants_profiler/index.htm
The memory and performance profiling are awesome. Being able to actually see proper numbers instead of guessing makes optimisation pretty fast. I've used it quite a bit at work for reducing the memory footprint of our main app.
Add code to the constructor of the
unamanaged object to log when it's
onstructed, and sort a unique ID.
Use that unique ID when the object
is destroyed again, and you can at
least tell which ones are going
astray.
Grep the code for every place you
construct a new object; follow that
code path to see if you have a
matching destroy.
Add chaining pointers to the
constructed objects, so you have a
link to the object constructed
before and after the current one. Then you can sweep through them later.
Add reference counters.
Is there a "debug malloc" available?
The managed debugging add in SoS (Son of Strike) is immensely poweful for tracking down managed memory 'leaks' since they are, by definition discoverable from the gc roots.
It will work in WinDbg or Visual studio (though it is in many respects easier to use in WinDbg)
It is not at all easy to get to grips with. Here is a tutorial
I would second the recommendation to check out Tess Fernandez's blog too.
How do you know for a fact that you actually have a memory leak?
One other thing: You write that your processing classes are using events. If you have registered an event handler it will keep the object that owns the event alive - i.e. the GC cannot collect it. Make sure you de-register all event handlers if you want your objects to be garbage collected.
Be careful how you define "leak". "Uses more memory" or even "uses too much memory" is not the same as "memory leak". This is especially true in a garbage-collected environment. It may simply be that GC hasn't needed to collect the extra memory you're seeing used. Also be careful about the difference between virtual memory use and physical memory use.
Finally not all "memory leaks" are caused by "memory" sorts of issues. I was once told (not asked) to fix an urgent memory leak that was causing IIS to restart frequently. In fact, I did profiling and found I was using a lot of strings through the StringBuilder class. I implemented an object pool (from an MSDN article) for the StringBuilders, and memory usage went down substantially.
IIS still restarted just as frequently. This was because there was no memory leak. Instead, there was unmanaged code that claimed to be thread-safe but was not. Using it in a web service (multiple threads) caused it to write all over the C Runtime Library heap. Since nobody was looking for unmanaged exceptions, nobody saw this until I happened to do some profiling with AQtime from Automated QA. It happens to have an events window, that happened to display the cries of pain from the C Runtime Library.
Placed locks around the calls to the unmanaged code, and the "memory leak" went away.
If your unmanaged object really is the cause of the leak, you may want to have it call AddMemoryPressure when it allocates unmanaged memory and RemoveMemoryPressure in Finalize/Dispose/where ever it deallocates the unmanaged memory. This will give the GC a better handle on the situation, because it may not realize there's a need to schedule collection otherwise.
You mentioned that your using events. Are you removing the handlers from those events when your done with your object? I've found that 'loose' event handlers will cause a lot of memory leak problems if you add a bunch of handlers without removing them when your done.
The best memory profiling tool for .Net is this:
http://memprofiler.com
Also, while I'm here, the best performance profiler for .Net is this:
http://www.yourkit.com/dotnet/download/index.jsp
They are also great value for money, have low overhead and are easy to use. Anyone serious about .Net development should consider both of these a personal investment and purchase immediately. Both of them have a free trial.
I work on a real time game engine with over 700k lines of code written in C# and have spent hundreds of hours using both these tools. I have used the Sci Tech product since 2002 and YourKit! for the last three years. Although I've tried quite a few of the others I have always returned to these.
IMHO, they are both absolutely brilliant.
Similar to Charlie Martin, you can do something like this:
static unigned __int64 _foo_id = 0;
foo::foo()
{
++_foo_id;
if (_foo_id == MAGIC_BAD_ALLOC_ID)
DebugBreak();
std::werr << L"foo::foo # " << _foo_id << std::endl;
}
foo::~foo()
{
--_foo_id;
std::werr << L"foo::~foo # " << _foo_id << std::endl;
}
If you can recreate it, even once or twice with the same allocation id, this will let you look at what is happening right then and there (obviously TLS/threading has to be handled as well, if needed, but I left it out for clarity).