Bug 209118 – [GTK] UI process crash when entering compositing mode when WPE_RENDERER is enabled

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Michael Catanzaro]

With WebKitGTK 2.28.0, libwpe 1.6.0, WPEBackend-fdo 1.6.0, in my rawhide VM, we have a showstopper UI process crash whenever entering AC mode, 100% reproducible. I don't know what to do about it because the crash occurs inside ffi_call():

#0  0x0000000000000000 in  ()
#1  0x00007fe93b9b1af0 in ffi_call_unix64 () at ../src/x86/unix64.S:76
#2  0x00007fe93b9b12ab in ffi_call (cif=cif@entry=0x7ffd94622210, fn=<optimized out>, rvalue=<optimized out>, 
    rvalue@entry=0x0, avalue=avalue@entry=0x7ffd946222e0) at ../src/x86/ffi64.c:525
        classes = {X86_64_INTEGER_CLASS, 32765, 1007101216, 21985}
        stack = <optimized out>
        argp = 0x7ffd946220d0 ""
        arg_types = <optimized out>
        gprcount = 2
        ssecount = <optimized out>
        ngpr = 1
        nsse = 0
        i = <optimized out>
        avn = <optimized out>
        ret_in_memory = <optimized out>
        reg_args = <optimized out>
#3  0x00007fe93a82acd2 in wl_closure_invoke
    (closure=closure@entry=0x55e13c072520, flags=flags@entry=2, target=<optimized out>, 
    target@entry=0x55e13cdb37e0, opcode=opcode@entry=6, data=<optimized out>, data@entry=0x55e13cf30600)
    at src/connection.c:1018
        count = 0
        cif = 
          {abi = FFI_UNIX64, nargs = 2, arg_types = 0x7ffd94622230, rtype = 0x7fe93b9b2180 <ffi_type_void>, bytes = 0, flags = 0}
        ffi_types = 
          {0x7fe93b9b2060 <ffi_type_pointer>, 0x7fe93b9b2060 <ffi_type_pointer>, 0x7fe93b9b20c0 <ffi_type_sint32>, 0x7fe93b9b20c0 <ffi_type_sint32>, 0x7fe93b9b20c0 <ffi_type_sint32>, 0x7fe93b9b20c0 <ffi_type_sint32>, 0x55e13c6300d0, 0x7ffd946222b0, 0x55e13cf30600, 0x55e13cf30cd0, 0x0, 0x55e13c146310, 0x55e13c14bff0, 0x7fe93a82971b <wl_connection_read+235>, 0x55e100000001, 0x55e13cf32ce0, 0x0, 0x7ffd00000000, 0x7ffd946222f0, 0x2, 0x7ffd94622310, 0x0}
        ffi_args = 
          {0x7ffd946221f0, 0x7ffd946221f8, 0x55e13cdb37e0, 0x7fe93a829be3 <wl_closure_init+147>, 0x55e13cd3b108, 0x4a36bd966fb7e700, 0x55e13cf30630, 0x55e13cf30600, 0x55e13cdb37e0, 0x55e13cf30cd0, 0x7fe93be060f0 <wl_surface_requests+144>, 0x7fe93a82a59c <wl_connection_demarshal+156>, 0x55e13c0725f8, 0x55e13cf30cd0, 0x55e13c0725f0, 0x55e13c072520, 0x83c072520, 0x7fe93a82a9ea <wl_closure_lookup_objects+58>, 0x7fe93be060f0 <wl_surface_requests+144>, 0x7fe93a824d80 <log_closure+64>, 0x7fe93be060f0 <wl_surface_requests+144>, 0x3a829ab5}
        implementation = <optimized out>
#4  0x00007fe93a826132 in wl_client_connection_data (fd=<optimized out>, mask=<optimized out>, data=0x55e13cf30600)
    at src/wayland-server.c:432
        client = 0x55e13cf30600
        connection = 0x55e13cf30cd0
        resource = 0x55e13cdb37e0
        object = 0x55e13cdb37e0
        closure = 0x55e13c072520
        message = 0x7fe93be060f0 <wl_surface_requests+144>
        p = {6, 524294}
        resource_flags = <optimized out>
        opcode = 6
        size = <optimized out>
        since = <optimized out>
        len = <optimized out>
#5  0x00007fe93a828bea in wl_event_loop_dispatch (loop=0x55e13c146310, timeout=timeout@entry=0) at src/event-loop.c:1027
        ep = {{events = 1, data = {ptr = 0x55e13ce06f40, fd = 1021341504, u32 = 1021341504, u64 = 94425877344064}}, {events = 32765, data = {ptr = 0x7ffd946224e0, fd = -1805507360, u32 = 2489459936, u64 = 140727092913376}}, {events = 0, data = {ptr = 0x3be067b000000000, fd = 0, u32 = 0, u64 = 4314562448632840192}}, {events = 32745, data = {ptr = 0x7fe93be02f80, fd = 1004547968, u32 = 1004547968, u64 = 140639708655488}}, {events = 0, data = {ptr = 0x3bdff6f300000000, fd = 0, u32 = 0, u64 = 4314438491581710336}}, {events = 32745, data = {ptr = 0x55e13c074180, fd = 1007108480, u32 = 1007108480, u64 = 94425863111040}}, {events = 1874323200, data = {ptr = 0x3c0740104a36bd96, fd = 1245101462, u32 = 1245101462, u64 = 4325496405821406614}}, {events = 21985, data = {ptr = 0x2f, fd = 47, u32 = 47, u64 = 47}}, {events = 0, data = {ptr = 0x3c07418000000000, fd = 0, u32 = 0, u64 = 4325497985124270080}}, {events = 21985, data = {ptr = 0x8, fd = 8, u32 = 8, u64 = 8}}, {events = 1004535980, data = {ptr = 0x3c0725f800007fe9, fd = 32745, u32 = 32745, u64 = 4325467714194800617}}, {events = 21985, data = {ptr = 0x4a36bd966fb7e700, fd = 1874323200, u32 = 1874323200, u64 = 5347670061366109952}}, {events = 1007101424, data = {ptr = 0x3c10cd20000055e1, fd = 21985, u32 = 21985, u64 = 4328184779225716193}}, {events = 21985, data = {ptr = 0x55e13c10d390, fd = 1007735696, u32 = 1007735696, u64 = 94425863738256}}, {events = 2, data = {ptr = 0x7fffffff00000000, fd = 0, u32 = 0, u64 = 9223372032559808512}}, {events = 0, data = {ptr = 0x55e13c08c920, fd = 1007208736, u32 = 1007208736, u64 = 94425863211296}}, {events = 977578768, data = {ptr = 0x3a49a32100007fe9, fd = 32745, u32 = 32745, u64 = 4200067489628979177}}, {events = 32745, data = {ptr = 0x55e13c07a040, fd = 1007132736, u32 = 1007132736, u64 = 94425863135296}}, {events = 1874323200, data = {ptr = 0x3c0740f84a36bd96, fd = 1245101462, u32 = 1245101462, u64 = 4325497402253819286}}, {events = 21985, data = {ptr = 0x55e13c10cd20, fd = 1007734048, u32 = 1007734048, u64 = 94425863736608}}, {events = 1007735696, data = {ptr = 0x6fb7e700000055e1, fd = 21985, u32 = 21985, u64 = 8050156846134089185}}, {events = 1245101462, data = {ptr = 0x7fffffff, fd = 2147483647, u32 = 2147483647, u64 = 2147483647}}, {events = 1007735696, data = {ptr = 0x94773a3a000055e1, fd = 21985, u32 = 21985, u64 = 10698083460624438753}}, {events = 32765, data = {ptr = 0x7ffd94622680, fd = -1805506944, u32 = 2489460352, u64 = 140727092913792}}, {events = 2489460224, data = {ptr = 0x9462267800007ffd, fd = 32765, u32 = 32765, u64 = 10692150762168942589}}, {events = 32765, data = {ptr = 0x7fffffff, fd = 2147483647, u32 = 2147483647, u64 = 2147483647}}, {events = 1089764432, data = {ptr = 0x100007fe9, fd = 32745, u32 = 32745, u64 = 4295000041}}, {events = 0, data = {ptr = 0x7fe9411f9635 <__GI___clock_gettime+37>, fd = 1092589109, u32 = 1092589109, u64 = 140639796696629}}, {events = 1, data = {ptr = 0x3c08c92000000000, fd = 0, u32 = 0, u64 = 4325928581365497856}}, {events = 21985, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 2489460352, data = {ptr = 0x3c1ae48000007ffd, fd = 32765, u32 = 32765, u64 = 4331025230077132797}}, {events = 21985, data = {ptr = 0x1, fd = 1, u32 = 1, u64 = 1}}}
        source = <optimized out>
        i = 0
        count = <optimized out>
        has_timers = <optimized out>
#6  0x00007fe93b51d7b3 in operator() (__closure=0x0, base=0x55e13c14bff0) at /usr/src/debug/wpebackend-fdo-1.6.0-1.fc33.x86_64/src/ws.cpp:120
        eventLoop = <optimized out>
        source = @0x55e13c14bff0: {static s_sourceFuncs = {prepare = 0x7fe93b51d420 <_FUN(GSource*, gint*)>, check = 0x7fe93b51d3c0 <_FUN(GSource*)>, dispatch = 0x7fe93b51d770 <_FUN(GSource*, GSourceFunc, gpointer)>, finalize = 0x0, closure_callback = 0x0, closure_marshal = 0x0}, source = {callback_data = 0x0, callback_funcs = 0x0, source_funcs = 0x7fe93b5262c0 <WS::ServerSource::s_sourceFuncs>, ref_count = 3, context = 0x55e13c08c920, priority = 0, flags = 35, source_id = 13, poll_fds = 0x55e13c1ef830 = {0x55e13c14c050}, prev = 0x55e13c1dc500, next = 0x55e13c5da400, name = 0x55e13c0c5c50 "WPEBackend-fdo::Host", priv = 0x7fe920010060}, pfd = {fd = 17, events = 25, revents = 1}, display = 0x55e13c0ae4c0}
#7  _FUN(GSource*, GSourceFunc, gpointer) () at /usr/src/debug/wpebackend-fdo-1.6.0-1.fc33.x86_64/src/ws.cpp:129
#8  0x00007fe94153276f in g_main_dispatch (context=0x55e13c08c920) at ../glib/gmain.c:3309
        dispatch = <optimized out>
        prev_source = 0x0
        was_in_call = <optimized out>
        user_data = 0x0
        callback = 0x0
        cb_funcs = 0x0
        cb_data = 0x0
        need_destroy = <optimized out>
        source = 0x55e13c14bff0
        current = 0x55e13c08c9e0
        i = 0
        __func__ = "g_main_dispatch"
#9  g_main_context_dispatch (context=0x55e13c08c920) at ../glib/gmain.c:3974
#10 0x00007fe941532af8 in g_main_context_iterate (context=context@entry=0x55e13c08c920, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4047
        max_priority = 2147483647
        timeout = 168
        some_ready = 1
        nfds = 6
        allocated_nfds = <optimized out>
        fds = 0x55e13cedc7a0
#11 0x00007fe941532bc3 in g_main_context_iteration (context=context@entry=0x55e13c08c920, may_block=may_block@entry=1) at ../glib/gmain.c:4108
        retval = <optimized out>
#12 0x00007fe94174888d in g_application_run (application=0x55e13c082720 [EphyShell], argc=<optimized out>, argv=<optimized out>) at ../gio/gapplication.c:2559
        arguments = 0x55e13c132c90
        status = 0
        context = 0x55e13c08c920
        acquired_context = <optimized out>
        __func__ = "g_application_run"
#13 0x000055e13b24f064 in main (argc=<optimized out>, argv=<optimized out>) at ../src/ephy-main.c:427
        option_context = <optimized out>
        option_group = <optimized out>
        error = 0x0
        user_time = 0
        arbitrary_url = <optimized out>
        ctx = <optimized out>
        mode = <optimized out>
        status = <optimized out>
        flags = <optimized out>
        desktop_info = <optimized out>

[Carlos Garcia Campos]

Could this be related to the sandbox too? Have you tried to disable it?

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #1)
> Could this be related to the sandbox too? Have you tried to disable it?

Just checked. Disabling the sandbox does not prevent this crash. (Disabling AC mode does prevent the crash.)

[Michael Catanzaro]

I also checked Fedora 31 and the crash is not occurring there, so it's probably a regression in either libwpe or wpebackend-fdo. (I'm not updating them to 1.6 in F31.)

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #3)
> I also checked Fedora 31 and the crash is not occurring there, so it's
> probably a regression in either libwpe or wpebackend-fdo. (I'm not updating
> them to 1.6 in F31.)

Confirmed. If I manually install libwpe 1.6.0 and wpebackend-fdo 1.6.0 from F32, then I'm able to reproduce the crash in F31.

[Michael Catanzaro]

I manually build libwpe 1.6.0, wpebackend-fdo 1.6.0, and WebKitGTK 2.28.0 in my JHBuild environment on F31. Can't reproduce there.

I guess we should disable WPE renderer in F32+ until we know what's wrong.

[Michael Catanzaro]

I've upgraded to F32 to start testing this. It appears to be a WebKit stable branch regression somewhere between 2.27.90 and 2.28.0. Will try to narrow it down more.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #6)
> I've upgraded to F32 to start testing this. It appears to be a WebKit stable
> branch regression somewhere between 2.27.90 and 2.28.0. Will try to narrow
> it down more.

Hm, that's wrong. It seems my build of 2.28.0 with WPE renderer disabled crashes in a different way when entering AC mode. So disabling WPE renderer did not work.

I still can't reproduce in my jhbuild environment even with F32 host system, which is quite frustrating. The only thing I can think of to try is to do a build with AC mode completely force-disabled.

[Michael Catanzaro]

Crash with WPE_RENDERER disabled (*not* this bug!) is:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f201e22fb43 in WebKit::LayerTreeHost::LayerTreeHost (this=this@entry=0x7f1eea8e3380, webPage=...) at ../Source/WebKit/Shared/CoordinatedGraphics/SimpleViewportController.h:47
47	    float pageScaleFactor() const { return m_pageScaleFactor; }
[Current thread is 1 (Thread 0x7f2016d56a80 (LWP 2))]
(gdb) bt
#0  0x00007f201e22fb43 in WebKit::LayerTreeHost::LayerTreeHost(WebKit::WebPage&)
    (this=this@entry=0x7f1eea8e3380, webPage=...)
    at ../Source/WebKit/Shared/CoordinatedGraphics/SimpleViewportController.h:47
#1  0x00007f201e22fdac in std::make_unique<WebKit::LayerTreeHost, WebKit::WebPage&>(WebKit::WebPage&) ()
    at ../Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.h:64
#2  WTF::makeUnique<WebKit::LayerTreeHost, WebKit::WebPage&>(WebKit::WebPage&) ()
    at DerivedSources/ForwardingHeaders/wtf/StdLibExtras.h:483
#3  WebKit::DrawingAreaCoordinatedGraphics::enterAcceleratedCompositingMode(WebCore::GraphicsLayer*)
    (this=this@entry=0x7f2008275000, graphicsLayer=graphicsLayer@entry=0x0)
    at ../Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:587
#4  0x00007f201e22fe4a in WebKit::DrawingAreaCoordinatedGraphics::graphicsLayerFactory() (this=0x7f2008275000)
    at ../Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:302
#5  0x00007f201f4ff8e3 in WebCore::RenderLayerCompositor::ensureRootLayer() (this=0x7f200826d948)
    at ../Source/WebCore/rendering/RenderLayerCompositor.cpp:3878
#6  0x00007f201f4ffe15 in WebCore::RenderLayerCompositor::enableCompositingMode(bool)
    (enable=<optimized out>, this=0x7f200826d948) at ../Source/WebCore/rendering/RenderLayerCompositor.cpp:358
#7  WebCore::RenderLayerCompositor::enableCompositingMode(bool) (this=0x7f200826d948, enable=<optimized out>)
    at ../Source/WebCore/rendering/RenderLayerCompositor.cpp:352
#8  0x00007f201f4ffff2 in WebCore::RenderLayerCompositor::updateBacking(WebCore::RenderLayer&, WebCore::RenderLayerCompositor::RequiresCompositingData&, WebCore::RenderLayerCompositor::CompositingChangeRepaint, WebCore::RenderLayerCompositor::BackingRequired) (this=this@entry=0x7f200826d948, layer=
    ..., queryData=..., shouldRepaint=shouldRepaint@entry=WebCore::RenderLayerCompositor::CompositingChangeRepaintNow, backingRequired=<optimized out>) at ../Source/WebCore/rendering/RenderLayerCompositor.cpp:1620
#9  0x00007f201f500f34 in WebCore::RenderLayerCompositor::computeCompositingRequirements(WebCore::RenderLayer*, WebCore::RenderLayer&, WebCore::LayerOverlapMap&, WebCore::RenderLayerCompositor::CompositingState&, WebCore::RenderLayerCompositor::BackingSharingState&, bool&)
    (this=0x7f200826d948, ancestorLayer=<optimized out>, layer=..., overlapMap=..., compositingState=..., backingSharingState=..., descendantHas3DTransform=<optimized out>) at ../Source/WebCore/rendering/RenderLayerCompositor.cpp:1069
#10 0x00007f201f500e15 in WebCore::RenderLayerCompositor::computeCompositingRequirements(WebCore::RenderLayer*, WebCore::RenderLayer&, WebCore::LayerOverlapMap&, WebCore::RenderLayerCompositor::CompositingState&, WebCore::RenderLayerCompositor::BackingSharingState&, bool&)
    (this=0x7f200826d948, ancestorLayer=<optimized out>, layer=..., overlapMap=..., compositingState=..., backingSharingState=..., descendantHas3DTransform=<optimized out>) at ../Source/WebCore/rendering/RenderLayerCompositor.cpp:1018

(truncated because gdb is hideously slow)

[Michael Catanzaro]

BTW, this is a web process crash. So:

 * WPE renderer enabled -> UI process crash
 * WPE renderer disabled -> web process crash
 * AC mode disabled -> no crashes

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #8)
> Crash with WPE_RENDERER disabled (*not* this bug!) is:

In this case (still *not* this bug!) it prints:

WaylandCompositorDisplay initialization: failed to connect to the Wayland display: webkitgtk-wayland-compositor-504bf1b8-826b-4353-8e83-771ec08bea4c

This one *is* a sandbox problem, WEBKIT_FORCE_SANDBOX=0 avoids the issue. I think nobody has ever tested non-WPE AC mode with the sandbox enabled. I'll report a separate bug for this and try to fix the sandbox.

I'm not going to attempt to debug the main WPE crash here, though, because I don't know how to debug an ffi crash where traditional backtraces are useless.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #10)
> This one *is* a sandbox problem, WEBKIT_FORCE_SANDBOX=0 avoids the issue. I
> think nobody has ever tested non-WPE AC mode with the sandbox enabled. I'll
> report a separate bug for this and try to fix the sandbox.

It's bug #209106.

[Дилян Палаузов]

How shall I compile WebKit 2.28 so that is stops crashing?  Will just WEBKIT_FORCE_SANDBOX=0 help?  I have
ENABLE_ACCELERATED_2D_CANVAS=OFF (AC mode?),
ENABLE_BUBBLEWRAP_SANDBOX=OFF,
ENABLE_SANDBOX_EXTENSIONS=OFF,
USE_WPE_RERDERER=OFF,
USE_WPE_VIDEO_PLANE_DISPLAY_DM=OFF
PORT=GTK
ENABLE_X11_TARGET=OFF
ENABLE_WAYLANT_TARGET=ON

[Michael Catanzaro]

(In reply to Дилян Палаузов from comment #12)
> How shall I compile WebKit 2.28 so that is stops crashing?  Will just
> WEBKIT_FORCE_SANDBOX=0 help?  I have
> ENABLE_ACCELERATED_2D_CANVAS=OFF (AC mode?),

No, that's not related to AC mode.

> ENABLE_BUBBLEWRAP_SANDBOX=OFF,

That's very dangerous. Don't use that.

> ENABLE_SANDBOX_EXTENSIONS=OFF,

That doesn't do anything. It's only used on Apple platforms.

> USE_WPE_RERDERER=OFF,

Yes, use this. That is the only flag you need to work around this bug. Using this flag exposes bug #209106, but I've just fixed that one.

> USE_WPE_VIDEO_PLANE_DISPLAY_DM=OFF

That's not a GTK port option, so it probably doesn't do anything either.

> PORT=GTK
> ENABLE_X11_TARGET=OFF
> ENABLE_WAYLANT_TARGET=ON

Those are OK (except for the typo).

[Дилян Палаузов]

My system crashes in fact as described at https://bugs.webkit.org/show_bug.cgi?id=209345, I have long disabled bubbled WPE.

[Michael Catanzaro]

OK, by some mercy, I've done a new Fedora build and it's fixed itself somehow. I'm pretty sure no WebKit or WPE changes are relevant here. Perhaps something bad had briefly snuck into the buildroot. Not sure.

Anyway, I'm going to close this, and celebrate.

[Adrian Perez]

(In reply to Michael Catanzaro from comment #15)
> OK, by some mercy, I've done a new Fedora build and it's fixed itself
> somehow. I'm pretty sure no WebKit or WPE changes are relevant here. Perhaps
> something bad had briefly snuck into the buildroot. Not sure.
> 
> Anyway, I'm going to close this, and celebrate.

🍻️🎉️

[Michael Catanzaro]

So after I reenabled this in Fedora, I immediately received another crash report, identical to the original one here. :/ Reopening.

[Carlos Garcia Campos]

(In reply to Michael Catanzaro from comment #17)
> So after I reenabled this in Fedora, I immediately received another crash
> report, identical to the original one here. :/ Reopening.

What wpebackend-fdo version is in F31 and F32? It should be easy to bisect if it's a regression of fdo. We should fix the bug instead of work around it by enabling the legacy wayland nested compositor.

[Michael Catanzaro]

F31 has wpebackend-fdo 1.4.0 and F32 has wpebackend-fdo 1.6.0, but I had previously determined this was not a wpebackend-fdo regression and not bisectable in WebKit. (If it was bisectable, I would have done so already.) But probably my previous results are all invalid, because we had a breakthrough today. I was discussing with Milan that I was unable to reproduce the crash anymore myself, and he mentioned that he was testing in a VM. Indeed, I can reproduce in a VM, so it seems this crash only occurs in VMs!

Now that we know the crash only occurs in VMs, it's probably bisectable. I will investigate and see if I can figure out whether the change is in wpebackend-fdo or in WebKit or somewhere else. And of course I'll bisect if possible.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #19)
> I was discussing with Milan that I was unable to
> reproduce the crash anymore myself, and he mentioned that he was testing in
> a VM. Indeed, I can reproduce in a VM, so it seems this crash only occurs in
> VMs!

Yes, now that I knew to test inside a VM, this became easy to bisect. It's wpebackend-fdo after all:

$ git bisect good
194f11762cedc1c58dfd89bc14073dba7ee269a0 is the first bad commit
commit 194f11762cedc1c58dfd89bc14073dba7ee269a0
Author: Zan Dobersek <[e-mail]>
Date:   Wed Jan 15 09:30:23 2020 +0100

    ws: also initialize SHM support, while only binding the Wayland display if the extension is available.

 src/ws.cpp | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

[Michael Catanzaro]

Hmmm... from about:gpu, using Boxes 3.36.2 and a Fedora 32 VM:

EGL_VERSION
1.4

EGL_VENDOR
Mesa Project

EGL_EXTENSIONS
EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_wayland EGL_EXT_platform_x11 EGL_MESA_platform_gbm EGL_MESA_platform_surfaceless EGL_EXT_platform_device EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_context_flush_control EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image_base EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_query_driver

Notice: no EGL_WL_bind_wayland_display (why not?). Prior to that commit, that would cause WS::Instance::initialize to fail. After, initialization continues and we get this runtime crash.

(I notice my VM also has no EGL_EXT_image_dma_buf_import or EGL_EXT_image_dma_buf_import_modifiers, which wpebackend-fdo also uses, but that seems to be optional and OK. My Fedora 32 host system does not even have EGL_EXT_image_dma_buf_import_modifiers.)

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #4)
> Confirmed. If I manually install libwpe 1.6.0 and wpebackend-fdo 1.6.0 from
> F32, then I'm able to reproduce the crash in F31.

I think this is where I went wrong. I probably ran that test in a F31 VM to avoid messing with my host system. Then:

(In reply to Michael Catanzaro from comment #5)
> I manually build libwpe 1.6.0, wpebackend-fdo 1.6.0, and WebKitGTK 2.28.0 in
> my JHBuild environment on F31. Can't reproduce there.

Here I would have been back to working on my host system. So my debugging attempts prior to today were likely invalid because I might have been indiscriminately switching between VM and host without realizing that the VM could be to blame for the crash. :D

[Michael Catanzaro]

Looks like https://github.com/Igalia/WPEBackend-fdo/issues/95.

[Carlos Garcia Campos]

Created attachment 396639 [details]
Patch

Please, let me know if this fixes the crash in the VM.

[Michael Catanzaro]

Comment on attachment 396639 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=396639&action=review

> Source/WebKit/UIProcess/gtk/AcceleratedBackingStoreWayland.cpp:101
> +        const char* extensions = eglQueryString(eglDisplay, EGL_EXTENSIONS);
> +        if (!GLContext::isExtensionSupported(extensions, "EGL_WL_bind_wayland_display"))
>              return false;

Doesn't it make more sense to check this first, instead of initializing wpebackend-fdo and then giving up here even if initialization succeeded?

[Michael Catanzaro]

Comment on attachment 396639 [details]
Patch

Crash is fixed!

[Carlos Garcia Campos]

Committed r260244: <https://trac.webkit.org/changeset/260244>