[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]

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

--- Comment #41 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to Carlos Garcia Campos from comment #38)
> we are already using this in 2.20 without any issues so far.

Bug #184869 looks suspicious. I wonder if that is going to be an issue.

(In reply to Carlos Garcia Campos from comment #40)
> 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.

Indeed....

Anyway, to commit without ifdefs, you know you need to convince Alex, not me.

> 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*.

I'll ask again: what's the plan to free these hardware resources when the web process crashes? Seems like any application expecting the web process to never crash is not going to last very long.

> 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.

That's a good point.

-- 
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/20180422/fdd51cb1/attachment-0001.html>