Zombie process leaks

[goonzoid]

When surfaces close, we sometimes fail to call wait/waitpid on the associated process, which results in it hanging around as a zombie for the lifetime of the Ghostty application. There is a related discussion which I had missed until making this issue at #3596.

I can reproduce this reliably on MacOS. Strangely, while we also fail to call waitpid on the subprocess on linux, it still gets reaped. I did some pretty deep digging trying to figure out what is causing this, but came up empty handed. Happy to discuss this aspect further and share what I tried if it becomes relevant.

Reproduction Steps

I've been able to reproduce this in both the GLFW and SwiftUI builds on MacOS.

1. Launch Ghostty
2. Create a new tab (so now you have two)
3. Close the tab using Ctrl-D at the prompt, or by running exit (closing the tab directly does not trigger this)
4. Take a look at the process tree. You should see a zombie process that is a direct child of the core ghostty process. On MacOS, this is the login(1) wrapper process. Depending on what you use to inspect the process tree, it may appear as <defunct>.

What's happening?

There are some longer explanations (largely correct, but perhaps a bit confused) in the edit history of this issue. Here's the short version after more debugging:

When the surface's subprocess exits independent of Ghostty, we null out the Command before calling stop on it, which means we never call waitpid. Simple as that.

The fix ended up being a bit more complicated, due to a quirk in the implementation of waitpid we were using in the Zig standard library, and because of the mysterious unknown force that's somehow causing the subprocess to be reaped already on linux. I'll discuss the details of the fix further in my PR to make reviewing easier.

[basile-henry]

So you don't think the process hanging around after Ctrl-D on Linux is related to this bug on MacOS?
There's more detail about the Linux version in this other discussion: #3495 (it's a shame they don't automatically cross link like issues do)

[goonzoid]

So you don't think the process hanging around after Ctrl-D on Linux is related to this bug on MacOS? There's more detail about the Linux version in this other discussion: #3495 (it's a shame they don't automatically cross link like issues do)

It's hard to say for sure. Unfortunately I don't have a working Linux machine at the moment to test with. The symptoms seem similar, but some details about the logs mentioned in the discussion you link to makes me uncertain that it's the same thing.

You could try building from my fork and seeing that fixes it. Let me know what happens if so!