Opening a new page when the system is low enough on memory leads to a "Blank page" instead of opening the "Most visited" page. The progress bar that shows the progress loading the new tab is stuck at around 10%, the URL bar is empty, and closing the tab takes up to 5 seconds, which points to the WebProcesses not responding (or not being started). epiphany-3.32.1.2-1.fc30.x86_64 webkit2gtk3-2.24.1-1.fc30.x86_64 In epiphany, the process-model is one-secondary-process-per-web-view, and max-processes to 5. The problem can be reproduced by opening loads of tabs until the problems occur. There's no warnings or anything else in the journal. I can provide more information if there is some runtime debug I can enable to make WebKit spit out information from the WebProcess, such as their stdout/stderr.
Would it be possible to get a bt of the WebProcess when that happens?
My theory is there's not enough memory to launch a new web process, so we can't show an error page because we need a new web process to show an error page. Or: could be the web process is being launched, crashes due to OOM, and then gets relaunched again continuously.
(In reply to Michael Catanzaro from comment #2) > My theory is there's not enough memory to launch a new web process, so we > can't show an error page because we need a new web process to show an error > page. > > Or: could be the web process is being launched, crashes due to OOM, and then > gets relaunched again continuously. It's not crashing or getting killed due to OOM, because I'd see that in the journal. It's (probably) silently not able to launch new WebProcesses, because of resource limitation. I have no way to know which resource is missing because I have no way to make WebKit spit out information about this failure. (In reply to Carlos Garcia Campos from comment #1) > Would it be possible to get a bt of the WebProcess when that happens? It's not a crash or a hang. If it were a hang, I don't know how I'd identify which one of the processes was associated with the the tab in question.
We have: g_error("Unable to fork a new child process: %s", error->message); when g_subprocess_launcher_spawnv fails.
(In reply to Carlos Garcia Campos from comment #4) > We have: > > g_error("Unable to fork a new child process: %s", error->message); > > when g_subprocess_launcher_spawnv fails. That didn't show up in my logs either. Could the controlling process be running out of file descriptors instead?