Bug 234748 - [GTK] (.NET Bindings) - Initializing WebKitGTK seems to cause new .Net Processes to never exit again
Summary: [GTK] (.NET Bindings) - Initializing WebKitGTK seems to cause new .Net Proces...
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: PC Linux
: P3 Normal
Assignee: Nobody
Keywords: Gtk
Depends on:
Reported: 2021-12-30 03:12 PST by Vincent Vollers
Modified: 2022-01-08 11:09 PST (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Vollers 2021-12-30 03:12:20 PST

I think there is an underlying issue with WebKitGTK and its interaction with currently existing .NET bindings on Linux. This is quite hard to pinpoint exactly and I hope someone here can verify this behavior and perhaps find a solution.

The moment an embedded WebKitGTK component / window is initialized, newly created Processes (new System.Diagnostics.Process) will never "exit". The reason I believe it might have something to do with WebKitGTK and the reason I'm filing a bug here is that the same happens with multiple/different bindings.

For example https://github.com/tryphotino/photino.NET , https://github.com/JBildstein/SpiderEye and https://github.com/GtkSharp/GtkSharp .

The common denominator seems to be they all use WebKitGTK as an embedded browser engine for Linux.

Steps to Reproduce: 

I've created several minimal sample applications for different bindings in this github issue: https://github.com/tryphotino/photino.NET/issues/74

All these sample applications do is run the test at the start (create a new process, run, wait for exit) and again after a WebKitGTK window has been initialized and destroyed.

Actual Results: 

The first test succeeds (the new process runs and exits). However, after a WebKitGTK window/component has been created, the second test fails. (it now keeps waiting on Process.WaitForExit)

Expected Results: 

Both tests to start a new process and exit normally.

Build Date & Hardware: 

The build underlying "apt-get install libgtk-3-dev libwebkit2gtk-4.0-dev" on 26 December 2021 on Ubuntu 20.10

Additional Builds and Platforms: 

Under other browser engines (on windows: WebView2 - Edge Chromium) it works as expected.
Comment 1 Michael Catanzaro 2021-12-30 07:01:12 PST
Where does your code iterate the default main context?
Comment 2 Vincent Vollers 2021-12-30 09:30:45 PST
(In reply to Michael Catanzaro from comment #1)
> Where does your code iterate the default main context?

If I understand your question correctly... (note that I don't talk to GLib/GTK/Webkit directly, this is all handled in the various libraries.)

in case of Photino, that is 

(with the initialization here
https://github.com/tryphotino/photino.Native/blob/ea3fac7e6377f965065fb14b5c6e66dd6573b58f/Photino.Native/Photino.Linux.cpp#L614 )

in case of SpiderEye:
gtk_main is referenced here

and called here 

which is called here

which is called here

which is the main loop, since that is called here in the example

(so, "ExampleApp" calls "Application.Run(Window window, string startUrl)" which calls "Application.Run()" which calls "GtkApplication.Run" which calls "Gtk.Main()" which is a binding to "gtk_main" in "libgtk-3.so")

and finally, in the case of GtkSharp:
this is a bit hard to say, since it uses a code generator to create the bindings (defined here for webkitgtk: https://github.com/GtkSharp/GtkSharp/tree/develop/Source/Libs/WebkitGtkSharp ).

The application enters the main loop as defined here

which runs some kind of dynamic library loader as defined here 

So, the above 3 binding libraries are all quite different... Photino seems to be the most straightforward to test against. (The code to reproduce the behavior against any library you can find in https://github.com/tryphotino/photino.NET/issues/74 )
Comment 3 Vincent Vollers 2021-12-30 09:36:03 PST
(In reply to Michael Catanzaro from comment #1)
> Where does your code iterate the default main context?

Sorry I was wrong about Photino, it waits/handles on the gtk_main event loop here
Comment 4 Vincent Vollers 2022-01-08 04:35:51 PST
The problem is fixed using a workaround in one of the libraries in the following pull request: https://github.com/tryphotino/photino.Native/pull/77

The underlying issue seems to be that webkit or gtk at some point changes the signal handling for SIGCHLD which stops other processes later on from receiving this signal. Thus causing the behavior as described.

The workaround is to save the original action in the binding library before calling certain webkit functions

struct sigaction old_action;
sigaction (SIGCHLD, NULL, &old_action);
sigaction (SIGCHLD, &old_action, NULL);

The original discussion and proposed workaround which solved this for me came from another project

I'm not sure where the actual solution would be, but perhaps this will help someone track down the actual underlying issue.
Comment 5 Michael Catanzaro 2022-01-08 06:25:06 PST
Following the linked discussions, I see this boils down to https://gitlab.gnome.org/GNOME/glib/-/issues/2216. Do you agree?
Comment 6 Michael Catanzaro 2022-01-08 06:26:04 PST
Probably fixed by https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2408?
Comment 7 Vincent Vollers 2022-01-08 10:39:20 PST
Yes, this looks like that (https://gitlab.gnome.org/GNOME/glib/-/issues/2216) is the underlying problem.

I'm happy a fix seems to be on the way in Glib. Will watch the issue and do some testing once it is merged and released.
Comment 8 Michael Catanzaro 2022-01-08 11:09:11 PST
OK, I'll close this for now. Feel free to reopen if that's not enough or you think we need to change something specific in WebKit, but it looks like WebKit does not handle SIGCHLD at all or use GChildWatch, so I doubt we're directly involved here.