CODEWITHSUNDEEP
c#memory-leaksfiledialogunmanaged-memoryperformance-monitor
Exergist
Exergist

Reputation: 157

Memory leak analysis and help requested

I've been using the methodology outlined by Shivprasad Koirala to check for memory leaks from code running inside a C# application (VoiceAttack). It basically involves using the Performance Monitor to track an application's private bytes as well as bytes in all heaps and compare these counters to assess if there is a leak and what type (managed/unmanaged). Ideally I need to test outside of Visual Studio, which is why I'm using this method.

The following portion of code generates the below memory profile (bear in mind the code has a little different format compared to Visual Studio because this is a function contained within the main C# application):

public void main()
{
    string FilePath = null;
    using (FileDialog myFileDialog = new OpenFileDialog())
    {
        myFileDialog.Title = "this is the title";
        myFileDialog.FileName = "testFile.txt";
        myFileDialog.Filter = "txt files (*.txt)|*.txt|All files (*.*)|*.*";
        myFileDialog.FilterIndex = 1;

        if (myFileDialog.ShowDialog() == DialogResult.OK)
        {
            FilePath = myFileDialog.FileName;
            var extension = Path.GetExtension(FilePath);
            var compareType = StringComparison.InvariantCultureIgnoreCase;
            if (extension.Equals(".txt", compareType) == false) 
            {
                FilePath = null;
                VA.WriteToLog("Selected file is not a text file. Action canceled."); 
            }
            else
                VA.WriteToLog(FilePath);
        }
        else 
            VA.WriteToLog("No file selected. Action canceled.");
    }
    VA.WriteToLog("done");
}

enter image description here

You can see that after running this code the private bytes don't come back to the original count and the bytes in all heaps are roughly constant, which implies that there is a portion of unmanaged memory that was not released. Running this same inline function a few times consecutively doesn't cause further increases to the maximum observed private bytes or the unreleased memory. Once the main C# application (VoiceAttack) closes all the related memory (including the memory for the above code) is released. The bad news is that under normal circumstances the main application may be kept running indefinitely by the user, causing the allocated memory to remain unreleased.

For good measure I threw this same code into VS (with a pair of Thread.Sleep(5000) added before and after the using block for better graphical analysis) and built an executable to track with the Performance Monitor method, and the result is the same. There is an initial unmanaged memory jump for the OpenFileDialog and the allocated unmanaged memory never comes back down to the original value.

Does the memory and leak tracking methodology outlined above make sense? If YES, is there anything that can be done to properly release the unmanaged memory?

Upvotes: 1

Views: 240

Answers (2)

manveti
manveti

Reputation: 1711

If repeated calls don't increase memory use, you don't have a memory leak, you have delayed initialization. Some components aren't initialized until you use them, so their memory usage isn't being taken into account when you establish your baseline.

Upvotes: 1

David Browne - Microsoft
David Browne - Microsoft

Reputation: 89361

Does the memory and leak tracking methodology outlined above make sense?

No. You shouldn't expect unmanaged committed memory (Private Bytes) always be released. For instance processes have an unmanaged heap, which is managed to allow for subsequent allocations. And since Windows can page your committed memory, it isn't critical to minimize each processes committed memory.

Upvotes: 2

Related Questions