[Webkit-unassigned] [Bug 183348] REGRESSION(r222772): [GTK][WPE] WebProcess from WebKitGtk+ 2.19.9x SIGSEVs in WebKit::WebProcess::ensureNetworkProcessConnection() at Source/WebKit/WebProcess/WebProcess.cpp:1127

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Apr 20 22:54:35 PDT 2018


https://bugs.webkit.org/show_bug.cgi?id=183348

--- Comment #40 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #39)
> > (In reply to Michael Catanzaro from comment #35)
> > Having special process termination
> > behavior for GTK/WPE will lead to more platform-specific problems in the
> > future.
> 
> With those reservations, I could r+ if you add platform #ifdefs, I guess, so
> that the code would at least not be secretly platform-specific and wouldn't
> need an owner. It just seems like such a shame to be using platform #ifdefs
> for code that has no reason to be platform-specific.

Because it doesn't really need platform ifdefs, this code depends on whether the connection is exiting in case of send sync message failure or not. It happens that only GTK and WPE change that setting in the web process to not exit in case of send sync failure, because we *need* to terminate the web process to ensure resources are properly freed. So, there are reasons for us to have a different behavior than other platforms, *not leaking resources*. If there are more problems in the future we will fix them, but not fixing this only because other platforms don't need to terminate the web process this way doesn't make sense either. Note that not exiting on send sync failure makes the process termination more consistent/deterministic, because without it sometimes we finish on exit(0) and sometimes we don't, depending on when the connection is closed. I've had to debug that process several times since WebKit2, and others too (ask Miguel), and it's a pain.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180421/73fd20be/attachment-0001.html>


More information about the webkit-unassigned mailing list