Regression: Bitmap finalized during Image.Save(Stream, ImageFormat) leaks native GDI+ memory

[avendel]

.NET version

.NET 10, but regression likely introduced in .NET 9. The problem occurs when referencing System.Drawing.Common version 9.0 or later. It is not related to runtime version.

Did it work in .NET Framework?

Not tested/verified

Did it work in any of the earlier releases of .NET Core or .NET 5+?

Yes, when referencing System.Drawing.Common version 8.0.

The problem might have been introduced with #10783 or #10784. Now, Save(Stream, ImageFormat) calls the internal CoreImageExtensions.Save, which passes the native pointer to GDI+ without keeping the image alive. The ImageCodecInfo overload calls GC.KeepAlive(this).

Issue description

Saving an image with Image.Save(Stream, ImageFormat) to a MemoryStream can leak native memory if nothing else references the image. The GDI+ bitmap is never freed, and a full GC with finalizers doesn't recover it. Disposing the image avoids the leak, and so does using the Save(stream, codec, null) overload instead.

A possible explanation: Save(Stream, ImageFormat) calls the internal CoreImageExtensions.Save, which passes the native pointer to GDI+ without keeping the image alive, while the ImageCodecInfo overload calls GC.KeepAlive(this). If the image is finalized while GDI+ is still saving it, GdipDisposeImage could fail, likely with ObjectBusy. Since Dispose ignores the status and clears the handle, the native bitmap would be orphaned.

Steps to reproduce

#:package System.Drawing.Common@10.0.12

using System.Diagnostics;
using System.Drawing;
using System.Drawing.Imaging;

long before = NativeMemory();

for (int i = 0; i < 200; i++) { SaveBitmap(); }
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

Console.WriteLine($"Leaked: {(NativeMemory() - before) / 1024 / 1024} MB");

// Nothing keeps the bitmap alive during Save, so it can be finalized while GDI+ is still saving it.
static void SaveBitmap() => new Bitmap(1500, 1500).Save(new MemoryStream(), ImageFormat.Bmp);

static long NativeMemory() => Process.GetCurrentProcess().PrivateMemorySize64 - GC.GetGCMemoryInfo().TotalCommittedBytes;

Save the code above as SaveLeak.cs and run it on Windows with the .NET 10 SDK:

> dotnet run -c Release -p:TargetFramework=net10.0-windows SaveLeak.cs
Leaked: 277 MB

The reported amount varies between runs, but it is never close to zero.

Expected: close to 0 MB. After a full GC with finalizers, all bitmap memory is freed.
Actual: hundreds of MB of native memory are never freed.

Changing the first line to #:package System.Drawing.Common@8.0.31 gives Leaked: 2 MB on the same runtime.

Release mode is required in order to reproduce the issue.

[avendel]

Some background on why the Bitmap can be finalized while Save is running: in optimized code, an object becomes eligible for collection as soon as nothing will use it again, even if one of its methods is still running. Once the native pointer has been read, Save no longer uses this, and the caller doesn't use the bitmap either.

From the C# standard, §7.9 Automatic memory management:

If neither the object nor any of its instance fields can be accessed by any possible continuation of execution, other than the running of finalizers, the object is considered no longer in use and it becomes eligible for finalization.

This is why a using statement avoids the leak: Dispose is called after Save returns, which keeps the bitmap alive for the whole call. It's also why the repro needs a Release build. I couldn't get it to leak in Debug builds.

Raymond Chen covers this in When does an object become available for garbage collection? from 2010.