Bug 279913 – [WPE][GTK] bwrap, flatpak-spawn, and xdg-dbus-proxy processes remain forever

• Status: NEW
• Component: WebKitGTK

[Michael Catanzaro]

Using WebKitGTK 2.46.0, the web process cache is failing to resume web processes in the web process cache before terminating the UI process. Suspended web processes just continue to exist forever unless the user manually sends SIGTERM/SIGKILL or similar. If the user sends SIGCONT, then the web process will resume, notice the UI process is gone, and immediately quit. We need to make sure the web process cache always sends SIGCONT.

I tricked myself into thinking bug #262794 would fix this, but apparently not.

[Michael Catanzaro]

We can probably

[Michael Catanzaro]

Um, we can probably just revert 247615@main if we can't figure out how to fix this, but likely something simple is wrong somewhere. I assume the UI process terminates without actually running the code that sends SIGCONT, but need to check.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #2)
> I assume the UI
> process terminates without actually running the code that sends SIGCONT, but
> need to check.

I enabled debug logging in my development build. It reliably calls WebProcessProxy::platformResumeProcess and the subprocesses resume and exit cleanly. i.e. the bug is not occurring. I don't know how to reproduce.

But in my main browser, Epiphany Tech Preview, I see dozens of leaked suspended processes. :( Since WebKit was able to send SIGSTOP successfully, we at least know that sending signals to the subprocess should work.

I do notice that when I uncleanly terminate the UI process with Ctrl+C, then the suspended web processes remain forever. I'm afraid we'll need a separate manager process to unsuspend them no matter what.

[Michael Catanzaro]

It's possible there is nothing wrong with WebProcessCache, and we only leak child processes when the UI process crashes. This theory is *probably* wrong, but it would explain things perfectly, and I don't know how else to explain what's happening. I run Ephy Tech Preview all day long and it does occasionally crash due to various bugs, so no surprise I would have a bunch of suspended subprocesses leftover from that.

[Michael Catanzaro]

I got as far as reverting this commit, fixing the merge conflicts, and even finished typing out the commit message. Then I decided to check System Monitor to see how many suspended processes I currently have.

None of the (very many) leaked processes I currently have are actually suspended. Something else is going wrong. Removing process suspension logic won't fix anything.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #0)
> I tricked myself into thinking bug #262794 would fix this, but apparently
> not.

Prior to bug #262794, we really *did* leak suspended processes in the web process cache. I guess there's just a different process leak now.

This new problem appears to be a leak of only the bwrap and flatpak-spawn intermediate processes, which is weird, because those should surely notice and quit when their child does.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #6)
> This new problem appears to be a leak of only the bwrap and flatpak-spawn
> intermediate processes, which is weird, because those should surely notice
> and quit when their child does.

We don't have any control over these intermediate processes, either. It must be a bug in flatpak itself.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #6)
> This new problem appears to be a leak of only the bwrap and flatpak-spawn
> intermediate processes, which is weird, because those should surely notice
> and quit when their child does.

Also the xdg-dbus-proxy processes.

The actual WebKit auxiliary processes have quit, after noticing their connection to the UI process closed.

[Michael Catanzaro]

Inspecting flatpak-spawn.c, I think the only way this happens is if the flatpak portal doesn't emit the SpawnExited D-Bus signal. (Or if flatpak-spawn is somehow broken and doesn't receive it for some reason.) Since xdg-dbus-proxy is still running as well, I *assume* the flatpak portal has failed to notice the WebKit auxiliary process exiting.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #3)
> I do notice that when I uncleanly terminate the UI process with Ctrl+C, then
> the suspended web processes remain forever. I'm afraid we'll need a separate
> manager process to unsuspend them no matter what.

Um, I nearly forgot about this. This remains a valid problem and is enough justification on its own to remove the process suspension logic. But I've now sidetracked this bug report a little, so I should report a separate bug for this now.

[Michael Catanzaro]

OK, surprise! When closing Epiphany just now with Ctrl+Q, I noticed a very slight UI process hang before it quit. That was this network process crash. For some reason, WebKit is launching a new network process right when it quits! No wonder the ProcessLauncher gets destroyed.

But it doesn't always happen. I don't know how to reproduce it yet.

I should report a new bug for this problem tomorrow.

[Michael Catanzaro]

Oops, I had intended to post comment #11 in bug #280003, not here.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #10)
> Um, I nearly forgot about this. This remains a valid problem and is enough
> justification on its own to remove the process suspension logic. But I've
> now sidetracked this bug report a little, so I should report a separate bug
> for this now.

Moved to bug #280014.

[Michael Catanzaro]

Currently I have:

 * 7 leaked flatpak-spawn processes for Newsflash
 * 11 leaked bwrap processes for Newsflash
 * 2 leaked xdg-dbus-proxy process for Newsflash
 * 0 leaked WebKit auxiliary processes for Newsflash

I think we have to conclude this is a flatpak bug. WebKit has no control over when these processes exit.

[Michael Catanzaro]

Reported https://github.com/flatpak/flatpak/issues/5946