gtk: Zombie processes/VRAM leak with "quit-after-last-window-closed = false"

[cuddleplush]

Issue

With quit-after-last-window-closed = false, ghostty doesn't handle opening and closing new windows very well, resulting in either a zombie process for each window, or just a ram/vram leak if also using gtk-single-instance = true. I'm not sure if I understand quit-after-last-window-closed correctly, but what I'm trying to do is have a ghostty "daemon" always running, which results in new windows having faster startup time. However, it seems that with that option ghostty keeps all windows alive, resulting in this behaviour.

Tested on: Hyprland, River

Relevant PR: #2021

Repro

quit-after-last-window-closed = false
gtk-single-instance = true # optional

Now open and close a bunch of ghostty windows. If doing it fast, you can quickly reach >2gb of vram usage.

Showcase

8mb.video-OU1-llM9bjSP.mp4

[mitchellh]

This would be a regression if true. Things to verify:

• is the GTK gl area being destroyed
• is the window being destroyed

If both of these are true this is a GTK issue and not ours. GTK owns the OpenGL video RAM and if we’re getting the GTK GL area destroy callback it’s up to them.

We can also verify our threads are being destroyed but it wouldn’t matter since we don’t own any of the video memory if the GL context is destroyed.

I bring this up because a couple community members awhile back realized it was their driver that was buggy and not Ghostty and this COULD be the case. The steps above are how we verify.

[cuddleplush]

Here's the log when closing a window:

debug(gtk): window close request

(process:15341): Gdk-CRITICAL **: 18:06:57.462: gdk_event_get_modifier_state: assertion 'GDK_IS_EVENT (event)' failed
debug(app): focus event focused=false
debug(gtk_surface): gl surface unrealized
debug(opengl): program destroyed id=363
debug(opengl): program destroyed id=360
Destroying EGL context
Destroying EGL context
debug(io_thread): mailbox message=termio.message.Message{ .focused = false }
debug(renderer_thread): mailbox message=renderer.message.Message{ .focus = false }
debug(gtk): tab box destroy
debug(gtk_surface): gl destroy
debug(renderer_thread): starting renderer thread shutdown
debug(renderer_thread): renderer thread exited
debug(io_thread): starting IO thread shutdown
debug(io_exec): process group killed pgid=18136
debug(io_exec): waitpid result=0
debug(io_exec): process group killed pgid=18136
debug(io_exec): waitpid result=18136
info(io_exec): read thread got quit signal
debug(io_thread): IO thread exited
info(surface): surface closed addr=7f6c549e2000
debug(gtk): window destroy

[mitchellh]

Thank you, the two key events that GTK fired:

debug(gtk_surface): gl destroy
debug(gtk): window destroy

The rest also is encouraging that we are freeing all our memory.

I want to verify myself but this is looking to me like GTK is holding onto the memory for whatever reason.

This could be a scenario where the memory is only held until something else needs it. I don't know if GTK, your GPU driver, or the kernel does this but on macOS for example, free often doesn't free any memory. The macOS kernel encourages applications to keep their memory until there is memory pressure that requires it. The entire macOS philosophy is: "if you have gigabytes of free memory, free does nothing" because its faster to reallocate in the future if the memory is already mapped into your user process process than it is to set that all up again.

Because of the above, macOS provides alternate memory reporting metrics that omit this "allocated but unused" memory. It is very common that macOS beta testers report leaking memory only to realize that it's this (in macOS terms, the "real memory" which can be inspected using official tools).

I don't know if this is what Linux/GTK/GPU is doing, but the evidence in the logs so far is that all memory is being freed. At the very least, the only thing I know for certain is that GTK is telling us the GL surface is destroyed (which frees all associated GPU memory).

[mitchellh]

Oh but a totally separate issue: if there are zombie processes that's a major issue. All of the above is about VRAM but I just remembered that this issue also claims there are zombie processes. So we should verify that separately. :)

[cuddleplush]

I'm also not sure how VRAM is handled in this scenario, but I think the zombie process problem is indeed the main issue here.
On my system, just having:

quit-after-last-window-closed = false
gtk-single-instance = false

is enough to see the problem: All ghostty windows will "daemonize" when they get closed. Resulting in a zombie ghostty process for each of them. I'm assuming the way quit-after-last-window-closed = false is supposed to work, is that you have one "original" ghostty process, that sits in the background, while all new processes attach to it? So, when a new ghostty window is closed, it's process should disappear, while the "original" stays?

[mitchellh]

I'm assuming the way quit-after-last-window-closed = false is supposed to work, is that you have one "original" ghostty process, that sits in the background, while all new processes attach to it? So, when a new ghostty window is closed, its process should disappear, while the "original" stays?

Yes but its not that complicated.

quit-after-last-window-closed = false just keeps the main GUI thread alive and lets the rest die. Normally, the GUI thread dies when all other threads die. In this case, I suspect all our threads are probably killed but our processes aren't for whatever reason.

[mitchellh]

I'm not able to reproduce zombie processes. With quit-after-last-window-closed = false (and GTK single instance on), every window destroyed is both reclaiming memory AND not leaving behind any zombie processes. There is a single ghostty process with no windows, and each invocation launches a new window in the single instance.

If I set gtk-single-instance = false, I get a ton of processes but that makes sense: each launch is launching a new process, and that process is staying alive after the window closes. Just as I configured/asked.

I suspect what's happening in your video is that each launch of Ghostty is resulting in a new process that isn't connecting to the single instance for whatever reason. Since you have quit-after-last-window-closed=false, when that window is closed, that process stays alive. That's exactly what you asked it to do!

I would look into how you're launching Ghostty and ensure it is connecting to the single instance.

[cuddleplush]

Yeah that's my mistake, that is the intended behavior with quit-after-last-window-closed = false and gtk-single-instance = false together, didn't realize. But the VRAM problem with gtk-single-instance=true remains for me. I should also specify that with this setup, I never had any zombie processes, only with both set to false, but again that was my mistake, not an issue.

As for launching, I've tried with just a keybind from my wayland comp, which is what I normally do, as well as only launching with a runner aka using the .desktop file, but both have the same results.

I do believe the new windows connect to the gtk instance fine, the log of the "original" process does show new windows being opened and closed, no errors.

I guess it could really be a driver issue, but I am on a well-supported modern AMD gpu, so I feel like it's still quite unlikely.

[mitchellh]

Yeah, let me look more into the VRAM issue then. I wasn't able to reproduce it but a lot of times these are system specific unfortunately. If I can't track down any leakage then I'm not sure if I can realistically resolve it.

[mitchellh]

Migrated this to a discussion to gather some more information. If we can find actionable items in here then we can peel off specific issues. This isn't closing the core issue at all, but this wasn't directly actionable or reproducible enough to keep it as an issue (i.e. the VRAM on my machine doesn't go up!)