[webkit-gtk] Sockets/file descriptors and the web extension
ericwill at redhat.com
Wed Dec 5 12:56:42 PST 2018
On 12/5/18 3:28 PM, Michael Catanzaro wrote:
> WebKit uses several child processes. A WebKitWebExtension is just a way
> to run code in the WebKitWebProcess. Each WebKitWebView corresponds to
> one WebKitNetworkProcess and one or more WebKitWebProcess processes.
> These will be created regardless of whether or not you use the
> WebKitWebExtension class to inject code into the WebKitWebProcess
> On Wed, Dec 5, 2018 at 1:51 PM, Adrian Perez de Castro
> <aperez at igalia.com> wrote:
>> Are you setting the close-on-exec flag  on the file descriptor? If
>> it may be as well that the file descriptor for the socket is being
>> by the child processes (WebKitNetworProcess, WebKitWebProcess, etc).
> This should not be possible. WebKit creates subprocesses using
> g_spawn_async() in ProcessLauncherGLib.cpp. You can review the relevant
> code in GLib's gspawn.c. After forking, GLib iterates through all open
> file descriptors (except stdin, stdout, and stderr) and sets FD_CLOEXEC
> on each one to ensure they get closed when it later calls exec.
> Otherwise, if Eclipse failed to set CLOEXEC itself, then the file
> descriptors would be leaked in the child process, and you would probably
> wind up with this socket in use or not available error. (This behavior
> can be disabled using the G_SPAWN_LEAVE_DESCRIPTORS_OPEN flag, but
> WebKit does not use this flag.)
This is very useful thank you, I am going to look into the closing of
the port/socket a bit more closely as I am starting to suspect the issue
lies there and not with WebKit.
> So Eric, you say "debugging shows that the web extension still holds
> onto the socket/file descriptor." Are you sure the affected file
> descriptor is really owned by the WebKitWebProcess? If so, something
> very weird is happening inside gspawn.c, because it shouldn't be possible.
This is what was provided to me by the end user, and it's observed that
the bug is reproducible in certain steps, only when a web extension is
created. However this again could be related to the closing of the
port/socket and not a WebKit issue. I'll look into it further.
>> On a different note, from the brief description if the use case you
>> gave on
>> your first e-mail, I think you can probably get things done without using
>> a WebKitWebExtension at all.
> Yes, if it's possible to avoid the need for a WebKitWebExtension
> altogether, that would be ideal.
I did not write the WebKit implementation for SWT, but IIRC the reasons
for using an extension are:
1) We have API that allows users to define JS functions which will (when
executed) return values back to SWT at the Java level. We accomplish by
creating an extension, registering a function, and communicating with
the main SWT Java process via DBus.
2) These functions need to be available all the time, meaning they need
to be re-registered whenever a page is refreshed. This means listening
to the "window-object-cleared" signal, and re-registering the JS
functions on page refresh.
3) There is also API which allows an SWT client to execute JS
is async. My colleague who implemented WebKit in SWT managed to
workaround this by using a web extension and DBus.
Anyway thank you for your help on such a vague kind of question, I'm
going to investigate the matter further with the bug reporter.
More information about the webkit-gtk