Bug 249272
| Summary: | [WPE][GTK] Robustly handle subprocess leaks | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
| Component: | WebKitGTK | Assignee: | Carlos Garcia Campos <cgarcia> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | bugs-noreply, mcatanzaro |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=247057 https://bugs.webkit.org/show_bug.cgi?id=241353 https://bugs.webkit.org/show_bug.cgi?id=250377 https://bugs.webkit.org/show_bug.cgi?id=257551 |
||
Michael Catanzaro
With no applications open on my desktop, I noticed I had 17 bwrap processes running, 18 flatpak-spawn processes, running, and 7 xdg-dbus-proxy processes. Clearly either flatpak or WebKit is leaking subprocesses. One is more likely than the other. ;) We need to investigate and figure out what is going on here.
Bug #247057 contains an example of a web process leak caused by a hang. But we should additionally improve our design to be more robust to such issues. For example, the UI process could kill web processes once the UI process is done with them, or at least on exit.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Michael Catanzaro
Another example web process leak in bug #241353. I'm not confident that the underlying problem there has been comprehensively resolved.
Michael Catanzaro
Carlos Garcia had a suggestions at https://bugs.webkit.org/show_bug.cgi?id=247057#c10:
"""
I guess the process leaks started after 247678@main, because now any process hang caused it to be leaked. Good thing is that now those hangs are noticeable, but leaking a process is by far worse. So, I think we should prevent the process leak even if that means we won't notice the hangs anymore (the one being debugged already would be great to fix though, I will move use a separate bug). The network process has a watchdog work queue to force a process exit after 10 seconds since the connection was closed. We could do the same for the web process.
"""
But I would enhance that a little: each auxiliary process should have a watchdog thread tied to its UI process connection, not just the web and network process.
We also need to figure out why we're leaking flatpak-spawn and bwrap and xdg-dbus-proxy processes. We seem to be leaking far more of these than we do auxiliary processes, which is weird. I would expect they're all designed to quit when the auxiliary process quits, but apparently something is wrong.
(And maybe we should talk more about https://commits.webkit.org/247678@main, because that should not be needed unless the kernel-level graphics driver is broken, and I'm really not convinced that WebKit upstream should care about such cases. Nothing userspace does should ever affect global kernel resources.)
Carlos Garcia Campos
Pull request: https://github.com/WebKit/WebKit/pull/8106
EWS
Committed 258380@main (ee52175fab81): <https://commits.webkit.org/258380@main>
Reviewed commits have been landed. Closing PR #8106 and removing active labels.
Michael Catanzaro
Just want to say: this was a really good decision. It's now much easier to debug these problems.