-
Notifications
You must be signed in to change notification settings - Fork 519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix leaked zombie processes when closing surfaces #4605
base: main
Are you sure you want to change the base?
Conversation
I checked out your branch on my Ubuntu 24.04 and built it ( Log output after pressing
|
Yikes! That’s no good. I think I know what the issue is though. Thanks for checking it out! I’ll try to get a Linux VM set up soon so that I can fix it correctly for both platforms. |
Okay, thanks to @slovdahl's feedback and a fresh look at the code, I realized there's a much simpler fix available, which I've just pushed. I think there's a higher than average risk of future bugs here with any slight changes in this area, so I still think it may be worth a rethink of much of subprocess management code. That said, this PR should fix at least some (possibly all) zombie leak cases without introducing any risk of us getting stuck in a loop and hanging. Note that I still haven't had a chance to test on Linux, so someone should definitely do that before we merge. |
I'm afraid the ghostty process still hangs when pressing |
Hmm, that's surprising. Is it possible that you're still building the previous version of my branch? Note that I did a force-push in order to update this PR, so you may need to do a hard reset or similar (a simple pull likely won't do it). |
Doing a first pull of your repo/branch and build now, let's see. |
When exiting the shell with ctrl+d or
Tried again with gtk-single-instance forced to false, but still the same. And with closing the window through Gnome / window manager:
During the gtk2 era when I used glib, it was also tricky to get threads to nicely quit. Resulted in 'the thread must always exit itself', you can't force-abort it from the main thread, or it will stay behind. But, as I said, that was ages ago, and I hope that modern Zig doesn't have the same issues as an ageing glib version :). |
Yeah, I deleted the local branch before fetching your branch again. Re-did it once more and verified I have d58b435 locally as my HEAD. Noticed something interesting now though. This is But, if I press |
Never tested more tabs, so I don't know the 'original' 1.0.0 / 1.0.1 behaviour. But this branch indeed 'hangs' / stalls when opening multiple tabs and closing one with ctrl+d. Funnily, if I 'split right' for example, it seems to close OK with ctrl+d. I don't know if it's related. But if I have an alacritty terminal running with If I then close the ghostty window with ctrl+d, the waits keep showing. If I type |
Likely unrelated: #3224 |
FWIW, windows close normally with |
Yeah, for me as well. The problem was never with windows not closing. The problem is with the ghostty process not exiting when the shell decides to quit. |
Built myself a debug build. All cases with only a single tab. On
Pressing the X button in the top right corner to close the window:
This PR when pressing
This PR when pressing the X button in the top right corner:
|
Thanks for all the info folks. Clearly I need to get a Linux test setup before proceeding much further. This all works well on MacOS (at least for me). I have some theories about what might be causing the stuck process, but don't want to keep guessing when I can't test it out locally. |
I tried to debut the GTK side of this a little bit. First time I'm touching both Zig and GTK, so bear with me.. 😁 I'm not sure if it's the problem, but one thing that I find a bit strange is that cc'ing @jcollie as the original author of the |
Small progress here: managed to get a linux environment stood up today, and can reproduce the behavior exactly as described above. Ran out of time to debug but should be able to get to that soon. |
Full discussion in #4554, which this fixes.
I don't love the way the
killCommand
function ends up looking here, but I believe it to be functionally correct.I think we would really benefit from reworking and simplifying much of this subprocess handling code, but it's quite involved and there is of course risk that we re-introduce these kinds of bugs again. I may have a play with it at some point.