| Summary: | [WPE][GTK] web-process-terminated signal not emitted for first web view when bubblewrap sandbox is enabled | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
| Component: | WebKitGTK | Assignee: | Carlos Garcia Campos <cgarcia> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | bugs-noreply, cgarcia, mcatanzaro |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=193117 https://bugs.webkit.org/show_bug.cgi?id=245784 |
||
| Bug Depends on: | |||
| Bug Blocks: | 206533 | ||
|
Description
Michael Catanzaro
2021-02-05 10:33:41 PST
(In reply to Michael Catanzaro from comment #0) > Maybe there is some bug (perhaps even a kernel > bug?) causing that to not work. I don't think so, I wrote a reduced testcase where the parent process opens a socketpair() and passes one end to a child process via bubblewrap, then the child process just exits. The parent process receives HUP on its end of the socket. I also modified the test to have the child just sleep, and manually sent it SIGTERM (which is how I test to manually trigger web-process-terminated). The parent process still receives the HUP event. Yet if that were happening in WebKit, then surely web-process-terminated would be emitted. Needs further investigation. I poked further. It seems the UI process is really not receiving G_IO_HUP, which means my simple test program does not properly emulate what WebKit is doing. Only the network process receives G_IO_HUP. This leaves the initial webview unusable. Incredibly, I noticed this bug only occurs for the first web view created by Epiphany. The second web view and all subsequent web views are always able to detect crashes, regardless of the order in which I kill the web views. This is weird, but it seems to be true. Is this still happening? (In reply to Carlos Garcia Campos from comment #3) > Is this still happening? Yes, I reproduced it again just now by opening Epiphany with only one overview tab and killing its sole WebKitWebProcess: the web view freezes instead of displaying the process crash error message. It's hard to imagine what's going wrong here. There's a real chance this could be a kernel bug. I've looked at this a bit. I have no idea what's going on, but I've tried several things. The problem is indeed that we don't get any io event on the socket when the connection is closed due to web process crash. I tried using select instead of GSocket monitor just to discard it's a gio issue, and it happened too. Then I tried not binding DBus session and atspi and then it worked. The problem, for some reason, only happens when we spawn xdg-dbus-proxy, it doesn't matter if it's session bus or atspi or both. I tried not spawning xdg-dbus-proxy with bwrap, but didn't fix anything. I found the problem. We run all subprocesses with G_SUBPROCESS_FLAGS_INHERIT_FDS. Since xdg-dbus-proxy is spawned right before the first web process, but after the socketpair for the web process has been called, it's inheriting the connected socket. When the first web process dies, the connection is still connected from the UI process to the xdg-dbus-proxy process, and hup signal is not emitted. I think we don't need to use G_SUBPROCESS_FLAGS_INHERIT_FDS, because we are already using g_subprocess_launcher_take_fd() to transfer the fds we want. I'll submit a patch. Pull request: https://github.com/WebKit/WebKit/pull/4094 Oh *wow* I think INHERIT_FDS was previously needed to transfer the WPE socket to the web process, but that shouldn't be needed nowadays. Committed 254232@main (63e2970f0f1b): <https://commits.webkit.org/254232@main> Reviewed commits have been landed. Closing PR #4094 and removing active labels. Regression in bug #245784 |