Memory held by the resources is not released even after disposing all the references in WPF when disabling prefer-32 bit in the application

[vsfeedback]

Hi,

I created a WPF application with byte array, memory stream and BitmapImage when a main page is loaded as in the below snippet.

public partial class MainWindow:Window     
{         
byte[] buffer;         
Stream stream;         
BitmapImage bitmap;         
public MainWindow()

{

InitializeComponent();

this. Loaded+=MainWindow_Loaded;

}

private void MainWindow_Loaded(object sender,RoutedEventArgs e)

{

buffer =newbyte[100000000];

stream =newMemoryStream(buffer);

bitmap =newBitmapImage();

bitmap. BeginInit();

bitmap. UriSource=newUri(@"Image file Path");

bitmap. EndInit();

}

}

When the main page is loaded, I noted down the memory (using Visual Studio Diagnostic tool) is raised to 160 MB.

I wrote a button click event and cleared all the resources properly in the event handler as in the below code snippet.

private void button_Click(object sender,RoutedEventArgs e)

{

Array.Clear(buffer,0, buffer. Length);

buffer =null;

stream. Close();

stream. Dispose();

bitmap. UriSource=null;

bitmap =null;

}

When test the memory in Visual Studio Diagnostic tool, I could see that the memory held by the resources is not released even after cleared and the memory stays at 160 MB.

When tried to call the Garbage collection as in the below code snippet, I could see only 5 MB is reduced and the memory still stays at 155 MB.

GC. Collect();

GC. WaitForPendingFinalizers();

I suspect memory leak in this. Can you please suggest me how to release the total memory held by the resources?

Note: Disable the Prefer-32 bit in the Application

MSDN forum reference link (for more details): https://social.msdn.microsoft.com/Forums/vstudio/en-US/4b519b48-e9c8-4a66-b051-ce8a0acde2a7/memory-held-by-the-resources-is-not-released-even-after-disposing-all-the-references-in-wpf?forum=wpf

Regards,

Deepak G

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/620424/memory-held-by-the-resources-is-not-released-even.html
VSTS ticketId: 937073
These are the original issue comments:
(no comments)
These are the original issue solutions:
(no solutions)

[WamWooWam]

This doesn't seem to be a bug? You're allocating a CLR array that's 100MB in size, it should be freed when the garbage collector decides it's no longer in use. There's no leak here.

[Deepak211]

it should be freed when the garbage collector decides it's no longer in use. There's no leak here.

I have the below two questions.

1. Why GC.Collect is not works in 64-bit process application (when disabling prefer-32 bit in the application)?
2. Why it works when enabling prefer 32-bit?

[mikedn]

I don't see any suspicious GC behavior. That stream holds a reference to the array so the array won't ever get GCed. Null out the stream if you want it to work as expected.

[WamWooWam]

GC.Collect won't necessarily free anything, it all depends on more variables than I can count, the .NET Garbage Collector is a complex beast.

[Deepak211]

Null out the stream if you want it to work as expected.

@mikedn , I have tried null out the stream too. But the behavior varies when enabling and disabling prefer 32-bit. The issue still occurs in disabling prefer-32 bit as I mentioned in my 2nd and 3rd reply in the below forum.

https://social.msdn.microsoft.com/Forums/vstudio/en-US/4b519b48-e9c8-4a66-b051-ce8a0acde2a7/memory-held-by-the-resources-is-not-released-even-after-disposing-all-the-references-in-wpf?forum=wpf

[mikedn]

Back when I played with this I wasn't able to detect any differences between 32 and 64 bit. Besides, even if there are some differences the main issue in your example is that you do not null out the stream and that prevents the array from being collected.

From your forum thread I gather that the issue is actually related to WPF's handling of images, something which your example doesn't illustrate. If you're having problems with handling large images in 32 bit then that might be a WPF real issue. But then large images and 32 bit is probably not a good mix and the normal solution would simply be to use 64 bit.

So I guess the question is what exactly are you doing - how large are those images? how many such images are trying to load? and so on.

[stevenbrix]

@Deepak211 I think your example is a little misleading, generally you need to ensure that 2nd Generation GC has run and actually released all the allocations marked for cleanup. If I change the button click handler to this and click it twice, you see that GC is properly cleaning everything up. In your example, while resources are marked for cleanup, there is nothing in your application causing GC to run again and actually cleanup the resources you've freed.

        private void button_Click(object sender, RoutedEventArgs e)
        {
            if (buffer != null)
            {
                Array.Clear(buffer, 0, buffer.Length);
                buffer = null;
                stream.Close();
                stream.Dispose();
                bitmap.UriSource = null;
                bitmap = null;
                stream = null;
            }


            GC.Collect();
            GC.Collect();
            GC.WaitForPendingFinalizers();
        }

Let me know if you are still seeing your issue if you change to this.

[weltkante]

@stevenbrix you probably meant

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

shouldn't need to call GC.Collect twice in a row, without arguments it should run a full GC of all generations (doc) so one call is enough. If anything you need to call it a second time after WaitForPendingFinalizers to collect objects which had a finalizer pending after the first call.

[stevenbrix]

@weltkante good to know! Honestly, I've always taken a sledgehammer approach and just do whatever seems to actually get GC to run 😂

I don't see any different behavior between the two, I still have to click the handler twice. Oddly enough, if I remove one of the GC.Collect() calls, then no matter how many times I click the handler, the memory stays allocated. Do you see something different?

[weltkante]

No I don't see anything obvious, unless you look at external measurements like process memory usage. The .NET runtime won't release GC'ed memory immediately to the OS in case it can reuse it for more allcoations. Eventually the heuristics will hand it back though if its not needed.

The VS diagnostic tool should report the cleanup immediately after the first click I think, unless it is also looking at process memory usage and not managed memory, but then it would be a VS tooling issue and not a .NET Core issue. In either case you can force a memory snapshot after the first click and look who is still keeping references to the stream. If you don't find any reference to your stream in the memory snapshot then its been collected and memory is ready for reuse. I can take a quick look when I'm at my VS 2019 machine tomorrow.

Anyways, this isn't a WPF bug regardless of all this, if I read this right OP is allocating a stream and then not even using it for the image. WPF can't do anything about that, it doesn't even have a reference to the stream to hold on to.

[stevenbrix]

Agreed that this isn't a WPF issue, although now I'm more interested in trying to understand the behavior I'm seeing. So if I take a snapshot of the heap before I click the button, and after I click the button once I see the difference I'd expect, which confirms your hypothesis that VS is showing process memory. I'd be curious to know what causes the CLR to free the heap memory allocated in the process.

I'm going to close this since this isn't an actual WPF issue. @Deepak211 let me know if you have any questions/concerns with this resolution. Thanks!

[weltkante]

I'd be curious to know what causes the CLR to free the heap memory allocated in the process.

Given the observations for this scenario I'd guess one trigger is having passed several full GCs without needing the memory. I'm sure there are other conditions and it probably behaves differently in other situations, these are just heuristics trying to optimize for the common scenarios. Note that the OS is very efficient in paging out unused memory on the fly, so its not very important to hand back memory immediately. Thats why there exist dedicated measures for "managed memory usage" and dedicated tools to inspect the managed heap, because the memory management can mask real memory leaks or look like leaks when there aren't any.

Adding some more info for the OP how to differentiate real memory leaks:

One thing which is typical for memory leaks is that the memory usage keeps growing when repeating the operation. This was not tested here, if you'd close and recreate the window repeatedly eventually the memory usage should stop growing. What you are observing for a single instance of the operation is just the .NET runtime keeping some memory reserved anticipating you to create more large objects. Without a continuously growing memory usage you can't speak of a leak.

Sometimes its really hard to detect small leaks this way because the caching behavior of the .NET runtime will mask small leaks (memory can go up slowly for hours and then suddenly drop a bunch so you can't identify trends very well), so an alternative way is to do object counts with memory snapshots. Repeat your operation you think of leaking and take snapshots every 10 or some rounds, if the objects counts of live object only keeps growing then you also have a leak.