Bug 158899 - [GTK] Subprocess leak
Summary: [GTK] Subprocess leak
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2016-06-17 20:53 PDT by Michael Catanzaro
Modified: 2016-06-20 10:25 PDT (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2016-06-17 20:53:47 PDT
I currently have one database process, two network processes, and 32 web processes running. But I have only one Epiphany instance with six tabs open. So we're leaking subprocesses. I've been hearing sporadic reports of this for some time, but I've never noticed it myself before now.

I have no clue what's causing this, but this should be entirely preventable on Linux using PR_SET_PDEATHSIG, which kills the child when the parent process dies. We should consider using this, but it might not be possible as we need to be careful not to kill child processes if they have e.g. cleanup work to do....

We should probably also make the UI process responsible for reaping child processes, so we don't need GLib's intermediate process that breaks the process hierarchy; that way it would be possible to tell which UI process corresponds to each subprocess.
Comment 1 Michael Catanzaro 2016-06-17 21:22:32 PDT
Plot twist: I closed Epiphany, and all of the above processes terminated. (I had assumed they were from some previously-closed instance of Epiphany.) So somehow we got one UI process with two network processes, and a bunch of web processes that did not correspond to any open tabs.
Comment 2 Carlos Alberto Lopez Perez 2016-06-20 09:40:16 PDT
Looking at the output of "pstree -pa" it looks like all the WebKit process inherit from pid1 rather than from the UI process (epiphany or minibrowser). I mean when everything is working as expected.

So unless I'm missing something, it don't looks like the webkit process are childs of the UI process
Comment 3 Michael Catanzaro 2016-06-20 10:25:59 PDT
Yes, that's intentional; we spawn an intermediary process that spawns the real subprocess and then immediately quits, to ensure the real subprocess gets parented by pid 1 so that the UI process doesn't have to worry about reaping it. To avoid that, we would have to pass G_SPAWN_DO_NOT_REAP_CHILD to g_spawn_async in ProcessLauncherGtk.cpp (and also reap the child processes when they quit).