164910 2016-11-18 04:07:21 -0800 [GTK] UI process crash in webkitWebViewBaseContainerAdd 2016-12-08 00:23:11 -0800 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build PC Linux NEW https://bugzilla.redhat.com/show_bug.cgi?id=1395352 https://bugzilla.redhat.com/show_bug.cgi?id=1399921 https://bugs.webkit.org/show_bug.cgi?id=147297 https://bugzilla.redhat.com/show_bug.cgi?id=1401851 https://bugzilla.gnome.org/show_bug.cgi?id=775632 P2 Major --- 1 mcatanzaro webkit-unassigned bugs-noreply cgarcia mcatanzaro muhammetk oldest_to_newest 1252640 0 mcatanzaro 2016-11-18 04:07:21 -0800 UI process crash in webkitWebViewBaseContainerAdd: Truncated backtrace: Thread no. 1 (10 frames) #2 XGetWindowAttributes at GetWAttrs.c:150 #3 gtk_socket_realize at gtksocket.c:420 #4 _g_closure_invoke_va at gclosure.c:867 #7 gtk_widget_realize at gtkwidget.c:5454 #8 gtk_widget_set_parent at gtkwidget.c:9566 #9 webkitWebViewBaseContainerAdd(GtkContainer*, GtkWidget*) at /usr/src/debug/webkitgtk-2.14.1/Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp:421 #10 g_cclosure_marshal_VOID__OBJECTv at gmarshal.c:2102 #11 _g_closure_invoke_va at gclosure.c:867 #14 gtk_container_add at gtkcontainer.c:1875 #15 WebKit::WebPageProxy::createPluginContainer(unsigned long&) at /usr/src/debug/webkitgtk-2.14.1/Source/WebKit2/UIProcess/gtk/WebPageProxyGtk.cpp:107 It looks exactly like bug #147297, but this crash is reported against 2.14.1 whereas that bug was fixed a while back. I've asked the reporter to say whether he was running under Wayland or X11. Full backtrace downstream, as usual. 1252641 1 mcatanzaro 2016-11-18 04:09:50 -0800 Note: I have 34 reports of this. 1253074 2 mcatanzaro 2016-11-19 06:47:49 -0800 (In reply to comment #0) > I've asked the reporter to say > whether he was running under Wayland or X11. It was Wayland, of course. We should never have gotten here.... 1254734 3 cgarcia 2016-11-30 03:14:25 -0800 Interesting, this should never happen. It would be interesting to have a bt of the WebProcess too. So, basically the WebProcess is sending the sync message CreatePluginContainer to the UI process. That happens from NetscapePluginX11::create(), but NetscapePluginX11 is only created by NetscapePluginUnix when the display is X11 one: #if PLATFORM(X11) if (PlatformDisplay::sharedDisplay().type() == PlatformDisplay::Type::X11) { m_impl = NetscapePluginX11::create(*this); if (!m_impl) return false; } #endif So, this means that for some reason in Wayland we have an X11 sharedDisplay at this point in the Web process. How is that possible? Could it be the fallback X11 display we create when GTK+ doesn't have an open display? See bug #164917. If that was the case, it's impossible that anything could be rendered. 1254810 4 mcatanzaro 2016-11-30 09:44:01 -0800 Oh boy, I should have included the user report as it just makes this more confusing: """ Description of problem: 1. Opened the web application 2. Searched for "Chip donanım test" in google 3. Opened two new tabs from the search results: http://www.chip.com.tr/donanim/ and http://www.chip.com.tr/inceleme/ 4. Web crashed. """ By "opened the web application" he means "started Epiphany", the commandline is just "epiphany". So apparently he was able to display google.com successfully in the UI process, somehow with PlatformDisplay::Type::X11, running under Wayland, just not the tab that created a browser plugin. This is quite confusing. 1254811 5 mcatanzaro 2016-11-30 09:45:46 -0800 Oh, I misread your comment. It must have been just the new web process that was somehow -- mysteriously -- started with the wrong PlatformDisplay. 1254821 6 mcatanzaro 2016-11-30 10:01:21 -0800 Looks like I read my bugmail in the wrong order today. I have another Bugzilla report in today: https://bugzilla.redhat.com/show_bug.cgi?id=1399921 Our analysis service thinks this crash is identical to bug #147297, but of course the cause must be different as you've since added guards that should avoid this. Crazy and hopefully wrong theory: is it possible that XWayland is being used for the plugin process...? 1255007 7 mcatanzaro 2016-11-30 15:07:12 -0800 (In reply to comment #3) > Interesting, this should never happen. It would be interesting to have a bt > of the WebProcess too. By the way, there are really two bugs here. One is that PlatformDisplay is set wrong in the web process (or plugin process?). The other is that that should never be able to crash the UI process, because the web process and the plugin process are both untrusted. So even though we don't know why the secondary process is broken, we should still fix the UI process. 1255331 8 mcatanzaro 2016-12-01 11:45:34 -0800 Muhammet (the reporter) says he can reproduce this whenever he tries. "Sometimes it crashed when I clicked the link to go to the next page of the website article, but mostly it crashed as soon as the page was loaded." I forgot he had a WebKit Bugzilla account, but of course he does because he submits Turkish translation updates here. CCing him now, so we don't have to play back-and-forth between Bugzillas anymore. 1256798 9 mcatanzaro 2016-12-06 08:03:41 -0800 I'm up to 331 reports of this crash, bumping Importance field. 1257060 10 mcatanzaro 2016-12-06 16:24:08 -0800 I got a response in https://bugzilla.gnome.org/show_bug.cgi?id=775632, the user installed the Flash plugin and now dictionary.cambridge.org always crashes. The users in the other bugs did not respond but I kinda suspect Flash is to blame there too. 1257663 11 muhammetk 2016-12-08 00:23:11 -0800 (In reply to comment #10) > I got a response in https://bugzilla.gnome.org/show_bug.cgi?id=775632, the > user installed the Flash plugin and now dictionary.cambridge.org always > crashes. The users in the other bugs did not respond but I kinda suspect > Flash is to blame there too. I have also verified that (via about:plugins) Flash plugin (Shockwave Flash 11.2 r202) was installed and enabled on my crashing epiphany browser. I removed the plugin (via dnf), and the browser hasn't crashed again so far.