locked
Memory Leak RRS feed

  • Question

  • First off I hope everyone's holidays went well!

    I am looking into an issue we have about a UCMA application leaking memory. If we leave our UCMA application (which runs as a service) up for a significant period of time, lets say 12 hours, it is leaking up and over the 1GB mark.

    I have hooked up several .NET memory profilers up to the code, however when the process is consuming 1GB, all of the profilers still show the largest consumer being 3MB of strings in memory. This makes me feel like the bloat might be in unmanaged code that these profilers aren't pointing out to us.

    Is there any UCMA classes that need to be explicitly disposed to release unmanaged resources? Similar to how you have to explicitly dispose Font, Brush etc in System.Drawing or they will leak and not be garbage collected.

    Any pointers would be great!

    Thanks and take care,
    Simon

    Monday, January 4, 2010 3:14 PM

Answers

  • I found the source of the leak and figured I should post here so people can also find it.

    It was related to WmaFileSource. We were removing it via Player.RemoveSource() as we cycled wma files, however we were not calling WmaFileSource.Close();

    This resulted in massive leaks as you can imagine. Although none of this showing up in a memory profiler, whether it was RedGate or .NET Memory Profiler.

    When looking at the documentation online, the Close method just simply says it closes the file source, however it doesn't document that if you don't call this, it will not be cleaned up via garbage collection.

    It should be documented that this method is required to be called to avoid memory leaks.

    Is it safe to assume that WmaFileSource allocates unmanaged resources for these files and this is why no profiler was able to pick up on it?

    Thanks for the help!
    • Marked as answer by Simon_pf Tuesday, January 5, 2010 3:59 PM
    Tuesday, January 5, 2010 3:59 PM

All replies

  • Common cause of such error is having a short lived object method registered as a handler for a long lived object. Please take a look at following posting from code project http://www.codeproject.com/KB/dotnet/Memory_Leak_Detection.aspx, it does describe the process for investigating such problem. First step is to find the objects, which are not getting cleaned up. 
    Posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, January 4, 2010 5:30 PM
  • Thanks for the reply adarsh.

    Would these leaks show up as leaks of the type from the delegate in the profiler? Or would they not be visible to managed code at all?

    I'll look into this however I'm curious why all the profilers only show the highest type having 3MB of usage (strings) and several gigabytes of memory unaccounted for in the profiler.

    Thanks and take care,
    Simon
    Monday, January 4, 2010 6:16 PM
  • I found the source of the leak and figured I should post here so people can also find it.

    It was related to WmaFileSource. We were removing it via Player.RemoveSource() as we cycled wma files, however we were not calling WmaFileSource.Close();

    This resulted in massive leaks as you can imagine. Although none of this showing up in a memory profiler, whether it was RedGate or .NET Memory Profiler.

    When looking at the documentation online, the Close method just simply says it closes the file source, however it doesn't document that if you don't call this, it will not be cleaned up via garbage collection.

    It should be documented that this method is required to be called to avoid memory leaks.

    Is it safe to assume that WmaFileSource allocates unmanaged resources for these files and this is why no profiler was able to pick up on it?

    Thanks for the help!
    • Marked as answer by Simon_pf Tuesday, January 5, 2010 3:59 PM
    Tuesday, January 5, 2010 3:59 PM