Bug 1311519 - WebKitWebProcess always crashes when accessing certain websites
WebKitWebProcess always crashes when accessing certain websites
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: webkitgtk4 (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomas Popela
Fedora Extras Quality Assurance
:
: 1292823 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-24 07:07 EST by Petr Šabata
Modified: 2016-03-15 18:56 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-27 14:55:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Full backtrace from the MiniBrowser (266.23 KB, text/plain)
2016-02-24 10:12 EST, Petr Šabata
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
WebKit Project 154777 None None None 2016-02-27 14:55 EST

  None (edit)
Description Petr Šabata 2016-02-24 07:07:03 EST
Description of problem:
Accessing certain websites, e.g. http://google.com/, crashes WebKitWebProcess with the following error being printed to the console:

(WebKitWebProcess:27329): Gdk-ERROR **: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 159 error_code 2 request_code 0 (core protocol) minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Version-Release number of selected component (if applicable):
gtk3-3.18.7-2.fc23.x86_64
webkitgtk4-2.10.7-1.fc23.x86_64

How reproducible:
Always. (depends on the website)

Steps to Reproduce:
1. Write a WK2 application, for example using the tutorial code:
   https://wiki.gnome.org/Projects/WebKitGtk/ProgrammingGuide/Tutorial
2. Point it to a problematic website, e.g. Google.
   sed -e 's/webkitgtk.org/google.com/' -i wk2tut.c
3. Build it.
   gcc wk2tut.c $(pkg-config --cflags --libs webkit2gtk-4.0 gtk+-3.0) -o wk2tut
4. Run it and see it fail.

Actual results:
The web process crashes almost immediately.

Expected results:
The app works.

Additional info:
This doesn't happen on my Gentoo box with net-libs/webkit-gtk-2.10.7 and x11-libs/gtk+-3.18.7.  Perhaps it's about some Fedora patches or build flags.
Comment 1 Tomas Popela 2016-02-24 07:33:14 EST
Hi Petr,
can you please prove more information? Backtrace would be really helpful there. Also can you try running:

/usr/bin/MiniBrowser https://www.google.com

if it crashes for you as well? I cannot reproduce the issue on my side.
Comment 2 Petr Šabata 2016-02-24 10:10:00 EST
(In reply to Tomas Popela from comment #1)
> Hi Petr,
> can you please prove more information? Backtrace would be really helpful
> there. Also can you try running:
> 
> /usr/bin/MiniBrowser https://www.google.com
> 
> if it crashes for you as well? I cannot reproduce the issue on my side.

It happens with the MiniBrowser too.  I'll get a backtrace and attach it here.
Comment 3 Michael Catanzaro 2016-02-24 10:12:29 EST
As the error message says, also use the GDK_SYNCHRONIZE environment variable, run in gdb, break on gdk_x_error; backtraces for X window system errors are useless otherwise.

A few more questions:

 * Does loading https://duckduckgo.com/?q=search+results cause a crash?
 * Does loading https://github.com/WebKit/webkit/commits/master cause a crash?
 * Does loading this page itself https://bugzilla.redhat.com/show_bug.cgi?id=1311519 cause a crash?
 * Does loading https://wiki.gnome.org/Projects/WebKitGtk/ProgrammingGuide/Tutorial cause a crash?

If the first two crash but not the last two, then this crash is associated with accelerated compositing mode; if so, we'll need graphics wizards to investigate, so let's reassign this to your graphics driver in that case.
Comment 4 Petr Šabata 2016-02-24 10:12 EST
Created attachment 1130241 [details]
Full backtrace from the MiniBrowser
Comment 5 Petr Šabata 2016-02-24 10:17:28 EST
(In reply to Michael Catanzaro from comment #3)
> As the error message says, also use the GDK_SYNCHRONIZE environment
> variable, run in gdb, break on gdk_x_error; backtraces for X window system
> errors are useless otherwise.

Ran with GDK_SYNCHRONIZE without breaking on gdk_x_error.  Is that usable?

> A few more questions:
> 
>  * Does loading https://duckduckgo.com/?q=search+results cause a crash?
>  * Does loading https://github.com/WebKit/webkit/commits/master cause a
> crash?
>  * Does loading this page itself
> https://bugzilla.redhat.com/show_bug.cgi?id=1311519 cause a crash?
>  * Does loading
> https://wiki.gnome.org/Projects/WebKitGtk/ProgrammingGuide/Tutorial cause a
> crash?
> 
> If the first two crash but not the last two, then this crash is associated
> with accelerated compositing mode; if so, we'll need graphics wizards to
> investigate, so let's reassign this to your graphics driver in that case.

Only the DuckDuckGo link crashes, the remaining three work fine.
Comment 6 Michael Catanzaro 2016-02-24 11:26:41 EST
Thanks. It's indeed s a problem with AC mode; I dunno why, but for some reason https://github.com/WebKit/webkit/commits/master always triggers AC mode for me, but not for some people.

It's a good backtrace, but I don't know what to do with it because I don't understand OpenGL. I will move it upstream so the right developers see it the next time I go through the webkitgtk4 bugs here.
Comment 7 Michael Catanzaro 2016-02-24 11:37:47 EST
cgarcia:  0x00007fb4c997e358 in WebCore::GLContext::createContextForWindow(wl_egl_window*, WebCore::GLContext*) (windowHandle=0x2800015, sharingContext=0x0)     at /usr/src/debug/webkitgtk-2.10.7/Source/WebCore/platform/graphics/GLContext.cpp:131         glxContext = std::unique_ptr<WebCore::GLContextGLX> containing 0x2800015         GLXWindowHandle = 41943061
cgarcia:  that looks suspicius, I think
cgarcia:  wl_egl_window* in GLContextGLX
Comment 8 Michael Catanzaro 2016-02-26 21:36:57 EST
Petr, do you know if this started happening very recently, or if it's been occurring for a while in rawhide?
Comment 9 Michael Catanzaro 2016-02-26 21:39:31 EST
Actually, I just noticed this is an F23 bug (because I had OpenGL use disabled in rawhide until very recently) so it's probably not any recent change.
Comment 10 Petr Šabata 2016-02-27 12:43:37 EST
No idea.  I hit this issue while trying to port jumanji to WK2.
It definitely doesn't happen with webkitgtk/webkitgtk3 :)
Comment 11 Michael Catanzaro 2016-02-27 15:00:47 EST
We have in trunk a new environment variable WEBKIT_DISABLE_COMPOSITING_MODE you could set that would probably be a workaround for this until it gets fixed... it's not in 2.10.7, but I've proposed it as a backport for the 2.10.8 release.
Comment 12 Petr Šabata 2016-02-28 06:15:04 EST
Okay, so it means it simply remains broken in Fedora.  Is that right?
Comment 13 Michael Catanzaro 2016-02-28 11:06:00 EST
(In reply to Petr Šabata from comment #12)
> Okay, so it means it simply remains broken in Fedora.  Is that right?

To be clear, I opened an upstream bug for this: https://bugs.webkit.org/show_bug.cgi?id=154777

so that people who understand this code will see it. And if it's fixed upstream, the fix will make its way into Fedora shortly after.

Also to be clear: most of your app's users will not be affected by this issue. This is somehow specific to your setup (though I'm not sure how). If AC mode was broken for many other users, there would be lots of other reports of it before now. Since AC mode uses your GPU, issues are often hardware-specific (though I'm not sure that's the case for this one).
Comment 14 Michael Catanzaro 2016-03-01 19:08:25 EST
*** Bug 1292823 has been marked as a duplicate of this bug. ***
Comment 15 Michael Catanzaro 2016-03-01 19:09:26 EST
In bug #1292823 I found another user with the same problem. Maybe there is something similar about your setups? What graphics cards, for instance?
Comment 16 Petr Šabata 2016-03-02 04:18:43 EST
(In reply to Michael Catanzaro from comment #15)
> In bug #1292823 I found another user with the same problem. Maybe there is
> something similar about your setups? What graphics cards, for instance?

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64
Comment 17 Carlos Alberto Lopez Perez 2016-03-15 11:41:19 EDT
What GL libraries do you use? Intel mesa?

Can you post the output of the commands glxinfo and eglinfo?

Not sure if fedora builds this utilities into any package, otherwise you can do this:

1) Build it:
wget ftp://ftp.freedesktop.org/pub/mesa/demos/8.3.0/mesa-demos-8.3.0.tar.gz
tar xfzv mesa-demos-8.3.0.tar.gz
cd mesa-demos-8.3.0
./configure && make -j8

2) Run it like:
./src/xdemos/glxinfo &> glxinfo_output.txt
./src/egl/opengl/eglinfo &> eglinfo_output.txt

And attach the *_output.txt files
Comment 18 Petr Šabata 2016-03-15 12:07:02 EDT
(In reply to Carlos Alberto Lopez Perez from comment #17)
> What GL libraries do you use? Intel mesa?

None, I guess.  I don't have mesa-dri-drivers installed.

> Can you post the output of the commands glxinfo and eglinfo?
> ./src/xdemos/glxinfo &> glxinfo_output.txt
> ./src/egl/opengl/eglinfo &> eglinfo_output.txt

They both fail.  I'll just put it here.

For glxinfo, I get:
Error: couldn't find RGB GLX visual or fbconfig
name of display: :0

For eglinfo, I get:
libEGL warning: DRI2: failed to open i965 (search paths /usr/lib64/dri)
libEGL warning: DRI2: failed to open i965 (search paths /usr/lib64/dri)
libEGL warning: DRI2: failed to open swrast (search paths /usr/lib64/dri)
eglinfo: eglInitialize failed

This could well be it.  However, webkit should handle this gracefully and not just crash.  I'll retest with mesa drivers installed.
Comment 19 Petr Šabata 2016-03-15 12:16:31 EDT
I don't observe the crash with mesa-dri-drivers installed.
Comment 20 Carlos Alberto Lopez Perez 2016-03-15 12:21:45 EDT
So I guess this is caused because WebKitGTK+ is crashing or rendering an empty window when the GL configuration is broken instead of falling back to just disabling AC in that case.
Comment 21 Michael Catanzaro 2016-03-15 13:34:55 EDT
(In reply to Petr Šabata from comment #18)
> (In reply to Carlos Alberto Lopez Perez from comment #17)
> > What GL libraries do you use? Intel mesa?
> 
> None, I guess.  I don't have mesa-dri-drivers installed.

I had no idea this was possible, should our WebKit packages have a Requires for this?

We have plans to drop support for rendering without OpenGL, so handling it gracefully is not a priority IMO.
Comment 22 Carlos Alberto Lopez Perez 2016-03-15 17:24:07 EDT
(In reply to Michael Catanzaro from comment #21)
> (In reply to Petr Šabata from comment #18)
> > (In reply to Carlos Alberto Lopez Perez from comment #17)
> > > What GL libraries do you use? Intel mesa?
> > 
> > None, I guess.  I don't have mesa-dri-drivers installed.
> 
> I had no idea this was possible, should our WebKit packages have a Requires
> for this?
> 

Users of proprietary drivers may have the GL support provided by packages with other names, or provided by libraries installed without packages (for example using a script downloaded from the vendor website).

Maybe an idea is declaring an optional dependency (recommends?) on something like virtual/opengl (if that is a thing).
Comment 23 Michael Catanzaro 2016-03-15 18:56:49 EDT
(In reply to Carlos Alberto Lopez Perez from comment #22) 
> Users of proprietary drivers may have the GL support provided by packages
> with other names, or provided by libraries installed without packages (for
> example using a script downloaded from the vendor website).
> 
> Maybe an idea is declaring an optional dependency (recommends?) on something
> like virtual/opengl (if that is a thing).

We don't have any proprietary drivers in Fedora, so no need for a virtual dependency, our only OpenGL implementation is mesa, to my knowledge.

The mesa spec is rather confusing: http://pkgs.fedoraproject.org/cgit/rpms/mesa.git/tree/mesa.spec

I see we have mesa-libGL (which Provides the virtual dep libGL) and mesa-libGLES packages. The libGL dependency is automatically handled by RPM via a soname dependency; I presume that would allow swapping it out with another libGL if desired.

Does mesa-libGL require mesa-dri-drivers to function correctly? It does not declare the Requires.

Note You need to log in before you can comment on or make changes to this bug.