The web-process-terminated signal is not emitted when a web process crashes with the bubblewrap sandbox enabled, which breaks Epiphany's web process crash error page. I have no idea why, since all we do is check whether the IPC socket is still open. Maybe there is some bug (perhaps even a kernel bug?) causing that to not work. The child process, bwrap, does die as expected, and we need to rework the code to check process exit status anyway in order to fix bug #193117, so any fix for that issue would probably fix this too.
(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