How do I dispose an Image correctly? (Memory usage going up up up)

[KoB-Kirito]

Hey,

I just use Imagesharp to Image.Load() a stream, then I mutate it, then I SaveAsPng(), and then it should be disposed by the using block.

I don't need that image now anymore. But it seems to stay in memory. To be more specific, ConfigurableArrayPool+Bucket keeps getting bigger and bigger.

I do this operation every minute or so and want to get rid of that pool after I'm done with one image.

How?

Here's some example code of how I use it, maybe I just do it wrong?

' Load
Using img = Image.Load(imgStream)
    'Mutate
    img.Mutate(Sub(x)
                    x.Resize(New ResizeOptions() With {
                      .Mode = ResizeMode.Pad,
                      .Size = New Size(2000, 1000),
                      .Position = AnchorPositionMode.Left
                    })
                  End Sub)

    'Save
    Using fs = IO.File.Create(imgPath)
        img.SaveAsPng(fs, New Formats.Png.PngEncoder With {.CompressionLevel = 6})
    End Using

' Close
End Using

' Why is there still stuff in memory at this point???

[JimBobSquarePants]

You must be using an old version to be using VB.NET since the language does not support the unmanaged keyword #1202.

Older versions contained a memory leak that was fixed back in January via #1074

Please note. We cannot support ImageSharp on VB.NET, nor can we support old versions.

[KoB-Kirito]

Uhm, I'm on 2.7.0, is that not the current one?
I had no problems using vb.net besides this memory behavior here.

[JimBobSquarePants]

There's no such thing as ImageSharp 2.7.0.

The latest ImageSharp version released on NuGet is https://www.nuget.org/packages/SixLabors.ImageSharp/1.0.0-rc0003

[KoB-Kirito]

Oh yea, woops wrong line.
Yes, I'm on 1.0.0-rc0003

[JimBobSquarePants]

OK.... The lack of unmanaged keyword stop you from using any of the generic types Image<TPixel> etc which means no per-pixel access.

Can you please post a memory dump demonstrating the growth?

cc/ @antonfirsov

[KoB-Kirito]

The growth is not really a problem atm, I got that partly solve by using GCLargeObjectHeapCompactionMode.CompactOnce and collecting, but rather the normal 250-300mb that stay in memory even after I close an image.

I'm kinda bad with debugging, could you tell me how I create that memory dump you need?^^'

[antonfirsov]

@JimBobSquarePants I think the posted use-case should be fine, since it doesn't use generic images or per-pixel access.

[antonfirsov]

@KoB-Kirito the answer for your question is here:
https://docs.sixlabors.com/articles/imagesharp/memorymanagement.html

Does it help? Is there anything left unexplained?

[KoB-Kirito]

[KoB-Kirito]

@antonfirsov Well, I think I got one with the task manager, but it's quite big. 487Mb zipped, can't upload it here.

[antonfirsov]

@KoB-Kirito can you upload it to WeTransfer.com (or similar) and share the link?

If you feel there is sensitive data you'd rather not share in public, send the link to the following temporary email address I just made: tayomet776@lege4h.com

[KoB-Kirito]

@antonfirsov Nothing sensitive, just random images from konachan. Didn't check how "sensitive" they are though xD
You should got the link.

[antonfirsov]

Thanks, got it! Will share with the rest of the team.

[KoB-Kirito]

My spagetthicode is open source, if it helps. WIP though.
https://github.com/KoB-Kirito/Jiraisho/blob/master/ProcessingLoop.vb#L139

[antonfirsov]

Ok, looks like there is no issue with the library. The dump I downloaded also supports this, since the memory used by our arrays / pools seems to be limited to 200MB.

@KoB-Kirito maybe you should check if you are disposing SystemDrawing / GDI resources properly. I'm afraid you are leaking unmanaged resources and GC.Collect only helps because it enforces execution of finalizers (which is not really reliable).

[KoB-Kirito]

@antonfirsov Thx for the log, very interesting. Your desktops were not visible, were they obscured by windows? Or do you run some kind of custom UI which was detected as windows? You should have debug images of the detection in C:\Users\anfirszo\Documents\Jiraisho\remaining.bmp
As I said, it's still wip and a lot of testing has to be done ^^'

As for the memory rising, it only started to do that after I implemented ImageSharp, I was sure it's the cause. And I'm not able to read that memory debugger correctly it seems...
I'll investigate on that. Thx for the help!

[antonfirsov]

If you ping me on jolowo8063@fazmail.net while my browser window with that temp-mail.org address is open, I will reply with the screenshot.

[KoB-Kirito]

@antonfirsov It's fine, I just wanted you to look at it and see if the desktop was visible and which windows obscured it. But looking at the log it seems they were just obscured, and the app skips until it's not. So that seems to work. As I said, you would have to disable "Settings>Output>Skip monitor if obscured".
Btw, you're kinda the first tester, thx xD
Btw2, the log gives your mail away, it's in one of the window titles. I have to fine-tune the logging levels still..

As for the memory problem. I looked into garbage collection and how it works. And it seems that this is just how it is supposed to work. It only collects after a certain threshhold, and especialy the LOH get's collected only if really needed, and I seem to have a lot in the LOH. Me having 32GB ram almost empty, that threshhold seems to be at 1,5GB. When I collect manually it's all removed, so I don't have leaking unmanaged memory.
So yeah, I only noticed after I implemented ImageSharp, as then it's size got noticeable with all those streams I'm using, but it's not the fault of ImageSharp.
So it's all fine, it just looks bad for the uninitiated user. So I'll just implement manual GC while idling. Beeing a loop-based app, that seems to be a good practice according to StackOverflow~
Learning about your memory management system was very helpfull nontheless, thanks much, also @JimBobSquarePants :)

[antonfirsov]

log gives your mail away

Damn, was too careless, deleted that comment.