Bug 1311519

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.

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

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.

Created attachment 1130241 [details]
Full backtrace from the MiniBrowser

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

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.

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

Petr, do you know if this started happening very recently, or if it's been occurring for a while in rawhide?

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.

No idea.  I hit this issue while trying to port jumanji to WK2.
It definitely doesn't happen with webkitgtk/webkitgtk3 :)

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.

Okay, so it means it simply remains broken in Fedora.  Is that right?

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

*** Bug 1292823 has been marked as a duplicate of this bug. ***

In bug #1292823 I found another user with the same problem. Maybe there is something similar about your setups? What graphics cards, for instance?

(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

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

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

I don't observe the crash with mesa-dri-drivers installed.

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.

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

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

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