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.
Where does your code iterate the default main context?
(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 )
(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
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.
Following the linked discussions, I see this boils down to https://gitlab.gnome.org/GNOME/glib/-/issues/2216. Do you agree?
Probably fixed by https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2408?
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.
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.