[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
Sat Apr 21 23:39:18 PDT 2018
https://bugs.webkit.org/show_bug.cgi?id=183348
--- Comment #42 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #41)
> (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.
Right, but you are not helping me on that either. I don't mind to add platform ifdefs, but I prefer not to precisely because it gives the message that the code is specific to GTK and WPE and not to the ports not failing on send sync message.
> > 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.
It's better to leak resources always on crash than leaking on crash but also randomly when normal terminating the web process.
> > 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/6f20157c/attachment-0001.html>
More information about the webkit-unassigned
mailing list