Bug 164910 – [GTK] UI process crash in webkitWebViewBaseContainerAdd

• Status: NEW
• Component: WebKitGTK

[Michael Catanzaro]

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.

[Michael Catanzaro]

Note: I have 34 reports of this.

[Michael Catanzaro]

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

[Carlos Garcia Campos]

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.

[Michael Catanzaro]

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.

[Michael Catanzaro]

Oh, I misread your comment. It must have been just the new web process that was somehow -- mysteriously -- started with the wrong PlatformDisplay.

[Michael Catanzaro]

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

[Michael Catanzaro]

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

[Michael Catanzaro]

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.

[Michael Catanzaro]

I'm up to 331 reports of this crash, bumping Importance field.

[Michael Catanzaro]

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.

[Muhammet Kara]

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