example_glfw_metal consumes too much RAM while in background (11+ GB)

[marcizhu]

Version/Branch of Dear ImGui:

Version: 1.74 WIP
Branch: master (commit b205ab01)

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_glfw.cpp + imgui_impl_metal.cpp
Operating System: macOS Catalina 10.15.1

My Issue:

While running the example app (imgui_demo.cpp), if the app goes to the background, it starts to consume more and more RAM until the system runs out and hangs. I've seen it consume up to 58 GB of RAM all by itself.

Screenshot

Here's an example of macOS' activity monitor showing 11.54 GB of RAM being used by the example app while in the background.

Standalone, minimal, complete and verifiable example:

Just compile the app inside examples/example_glfw_metal from commit b205ab01 using GNU Make, run the executable, and place any other application on top of it, covering the entire app, for example Safari, Sublime Text... I found out that any app in full screen invokes this behavior . After that, It will start to memory leak and consume more and more resources pretty much instantaneously.

[marcizhu]

I've just tested this with the latest commit (bf6d1ba) and it shows the same exact behavior

[ocornut]

Hello,
Thank you for reporting. Looks like there is a leak somewhere. Tagging @warrenm who might have an idea?

[marcizhu]

Thanks for the quick response!
I agree, this looks like a memory leak, but for some reason it only happens when the app goes into the background. When it's running in the foreground, the app only uses 200-300 Mb, which is perfectly fine.

I'm trying to provide all the information I have in order to fix this. If I discover anything new, I'll post it here :)

[bear24rw]

I traced it down to id<CAMetalDrawable> drawable = [layer nextDrawable]; leaking IOSurfaces. I think what is happening is that when the window is covered App Nap kicks in (like in #1765) which pauses the underlying macos app event loop which causes the main threads default autoreleasepool to not drain (https://stackoverflow.com/a/34263858/253650). It seems the recommended way is to wrap everything in a @autoreleasepool block.

Unfortunately this is kind of ugly as it adds another nesting level, maybe there is a better solution? I pushed a branch that adds the @autoreleasepool wrapper if we want to go with that (bear24rw@90d2b00).

[warrenm]

That’s the conclusion I came to as well, and I think this is the correct solution.

[marcizhu]

I've just tested the branch at bear24rw@90d2b00 and it works perfectly! It runs at a constant 40-65 Mb of RAM, independently of it being in the background or in the foreground.

I think this could be the way to fix it.

[ocornut]

Max fix is now merged, thanks a lot!
I agree it looks a little bit fishy to have to do it this way, but I'm not familiar with Metal nor ObjC so I'll trust your judgment on this.