[GTK] (.NET Bindings) - Initializing WebKitGTK seems to cause new .Net Processes to never exit again

• Component: WebKitGTK
• Status: RESOLVED MOVED

[Vincent Vollers]

Overview: 

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.

[Michael Catanzaro]

Where does your code iterate the default main context?

[Vincent Vollers]

(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 
https://github.com/tryphotino/photino.Native/blob/ea3fac7e6377f965065fb14b5c6e66dd6573b58f/Photino.Native/Photino.Linux.cpp#L421

(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
https://github.com/JBildstein/SpiderEye/blob/3830876e5aa5efcaa5e54828a0b95c8824c0df07/Source/SpiderEye.Linux/Native/Gtk.cs#L242

and called here 
https://github.com/JBildstein/SpiderEye/blob/3830876e5aa5efcaa5e54828a0b95c8824c0df07/Source/SpiderEye.Linux/GtkApplication.cs#L25

which is called here
https://github.com/JBildstein/SpiderEye/blob/3830876e5aa5efcaa5e54828a0b95c8824c0df07/Source/SpiderEye.Core/Application.cs#L87

which is called here
https://github.com/JBildstein/SpiderEye/blob/3830876e5aa5efcaa5e54828a0b95c8824c0df07/Source/SpiderEye.Core/Application.cs#L114

which is the main loop, since that is called here in the example
https://github.com/JBildstein/SpiderEye/blob/3830876e5aa5efcaa5e54828a0b95c8824c0df07/Examples/Simple/App.Core/ProgramBase.cs#L14

(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
https://github.com/GtkSharp/GtkSharp/blob/a23d44fb82975711cfcaa400cd7f3e4988d15bbf/Source/Libs/GioSharp/Application.cs#L35

which runs some kind of dynamic library loader as defined here 
https://github.com/GtkSharp/GtkSharp/blob/1fb5527458ae37620dbcae90a97204da41b2ef7a/Source/Libs/Shared/GLibrary.cs


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 )

[Vincent Vollers]

(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
https://github.com/tryphotino/photino.Native/blob/ea3fac7e6377f965065fb14b5c6e66dd6573b58f/Photino.Native/Photino.Linux.cpp#L540

[Vincent Vollers]

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
https://github.com/akirakyle/emacs-webkit/issues/28.

I'm not sure where the actual solution would be, but perhaps this will help someone track down the actual underlying issue.

[Michael Catanzaro]

Following the linked discussions, I see this boils down to https://gitlab.gnome.org/GNOME/glib/-/issues/2216. Do you agree?

[Michael Catanzaro]

Probably fixed by https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2408?

[Vincent Vollers]

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.

[Michael Catanzaro]

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.