System.Drawing.Graphics memory leak when multi-threading on Linux

[tsvx]

This is a duplicate of the bug in the libgdiplus since I do not know exactly what leads to the problem.

Description

Consider this following piece of code:

async Task DrawCollage()
{
    var jpegBytes = File.ReadAllBytes("image.jpg"); // any 2000*1500 px, 24 bpp
    using var collage = new Bitmap(1000, 1000);
    using var g = Graphics.FromImage(collage);
    //using var ms = new MemoryStream(jpegBytes);
    //using var image = Image.FromStream(ms);
    //g.DrawImage(image, 0, 0, 500, 500);
}

Note that every graphics object is disposed properly here.

Frequent serialized calls of this method on different threads lead to enormous memory consumption, even with three last lines commented out. Working Set size increases in proportion to the number of threads involved, but GC Heap does not increase.
Uncommenting every line triples the memory consumption.

When I force this method to use one dedicated thread only, no increase in memory consumption is observed.

I expect the memory should not grow as every graphic object is disposed after use.

Configuration

• Ubuntu 18.04 x86_64
  • libgdiplus 4.4, 6.0.5
• Ubuntu 18.04 arm64
  • libgdiplus 4.2-2
• Debian 10 x86_64 (docker, mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim)
• .NET Core 3.1
• System.Drawing.Common 5.0.2

Regression?

The bug is not reproducible on Windows 10 x64 with .NET Core 3.1.

Other information

It seems something keeps being cached after dispose in the thread local storage in the libgdiplus library.

Note that the memory does not grow (no visible growth) if the considered task runs infrequently.

A complete code example to reproduce the problem is here: https://github.com/tsvx/SystemDrawingMemoryLeak
It is a work in progress (it reproduces the problem but can be simplified I think).

[ghost]

Tagging subscribers to this area: @safern, @tarekgh
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Consider this following piece of code (drawing a collage):

async Task DrawCollage()
{
    var jpegBytes = File.ReadAllBytes("image.jpg"); // any 2000*1500 px, 24 bpp
    using var collage = new Bitmap(1000, 1000);
    using var g = Graphics.FromImage(collage);
    //using var ms = new MemoryStream(jpegBytes);
    //using var image = Image.FromStream(ms);
    //g.DrawImage(image, 0, 0, 500, 500);
}

Frequent serialized calls of this method on different threads lead to enormous memory consumption, even with three last lines commented out. Working Set size increases in proportion to the number of threads involved, but GC Heap does not increase.

When I force this method to use one dedicated thread only, no increase in memory consumption is observed.

Seems like something is cached in the thread local storage in the libgdiplus library.

Configuration

• Ubuntu 18.04 x86_64
  • libgdiplus 4.4, 6.0.5
• Ubuntu 18.04 arm64
  • libgdiplus 4.2-2
• Debian 10 x86_64 (docker, mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim)
• .NET Core 3.1
• System.Drawing.Common 5.0.2

Regression?

The bug is not reproducible on Windows 10 x64 with .NET Core 3.1.

Other information

Author:	tsvx
Assignees:	-
Labels:	area-System.Drawing, untriaged
Milestone:	-

[colin-ife-snyk]

Hi @tsvx
Thanks for raising this issue. I'm interested to know if you think there are significant security implications of this memory leak (i.e. a malicious user could exploit it to crash an application or server), or whether it's just a performance issue?
Thanks!

[botinko]

We faced the same problem. In our case, it leads to denial of service, since there are limits on memory consumption in k8s.
Any service that uses System.Drawing.Graphics for image processing is subject to such a threat.

[safern]

@tsvx thank you for raising the issue. I did look at this and it seems like it is libgdiplus specific, there is a lot of memory that they are missing to free when disposing a graphics object.

Any service that uses System.Drawing.Graphics for image processing is subject to such a threat.

Agreed, and we have stated in our documentation that we don't recommend System.Drawing.Common on services like web servers, also it is not. thread safe.

I'm going to close this issue as it is libgdiplus specific and also because of a lot of other reasons we have decided to make System.Drawing.Common a windows only library as it is legacy and very tight to winforms. Plus there are better libraries out there for xplat memory manipulation or graphics, like SkiaSharp, ImageSharp or Microsoft.Maui.Graphics.

Please read this document for more information about this decision and let us know if you have any questions: https://github.com/dotnet/designs/blob/main/accepted/2021/system-drawing-win-only/system-drawing-win-only.md