Bug 1842473

I don't see any evidence that this would be fixed in 2.29.1. I won't upgrade F31/F32 to unstable WebKit anyway. If it's really fixed in 2.29.1, which I doubt, then we'd need to identify the related commit and request it be backported to the next 2.28 release.

Anyway, to make progress, please post a proper backtrace taken with gdb 'bt full', showing where in libnvidia-egl-wayland the crash occurs. You're lucky that component is open source, because otherwise this would be CANTFIX.

That webkit2gtk3 part is huge so I pasted the "bt full" here: https://l.r3pek.org/288be

This is just the first 14 calls.

(gdb) bt full
#0  0x00007ffff3a9c625 in raise () at /lib64/libc.so.6
#1  0x00007ffff3a858d9 in abort () at /lib64/libc.so.6
#2  0x00007ffff3a857a9 in _nl_load_domain.cold () at /lib64/libc.so.6
#3  0x00007ffff3a94a66 in annobin_assert.c_end () at /lib64/libc.so.6
#4  0x00007fffe4109b7d in wlExternalApiLock () at ../src/wayland-thread.c:87
        __PRETTY_FUNCTION__ = "wlExternalApiLock"
#5  0x00007fffe410e4ab in wlEglGetInternalHandleExport (dpy=0x5555566dad60, type=13233, handle=0x5555566dad60) at ../src/wayland-eglhandle.c:146
#6  0x00007fffd65574ef in  () at /lib64/libEGL_nvidia.so.0
#7  0x00007fffd64deeeb in  () at /lib64/libEGL_nvidia.so.0
#8  0x00007fffe410b752 in wl_eglstream_display_bind (data=data@entry=0x5555566cc5c0, wlDisplay=wlDisplay@entry=0x55555649b360, eglDisplay=eglDisplay@entry=0x5555566dad60)
    at ../src/wayland-eglstream-server.c:311
        wlStreamDpy = 0x555556b69f90
        exts = 0x0
        env = 0x0
#9  0x00007fffe410a355 in wlEglBindDisplaysHook (data=0x5555566cc5c0, dpy=0x5555566dad60, nativeDpy=0x55555649b360) at ../src/wayland-egldisplay.c:87
        res = 0
#10 0x00007fffd65533f3 in  () at /lib64/libEGL_nvidia.so.0
#11 0x00007fffd64db775 in  () at /lib64/libEGL_nvidia.so.0
#12 0x00007ffff20f5b11 in WS::Instance::initialize(void*) () at /lib64/libWPEBackend-fdo-1.0.so.1
#13 0x00007ffff49c7bf6 in WebKit::WebProcessPool::platformInitializeWebProcess(WebKit::WebProcessProxy const&, WebKit::WebProcessCreationParameters&) (this=this@entry=0x7fffe42ee000, process=
    ..., parameters=...) at ../Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp:119
#14 0x00007ffff489adfa in WebKit::WebProcessPool::initializeNewWebProcess(WebKit::WebProcessProxy&, WebKit::WebsiteDataStore*, WebKit::WebProcessProxy::IsPrewarmed)
    (this=<optimized out>, process=..., websiteDataStore=0x7fffe42e4000, isPrewarmed=WebKit::WebProcessProxy::IsPrewarmed::No) at ../Source/WebKit/UIProcess/WebProcessPool.cpp:1044
        initializationActivity = {m_ref = std::unique_ptr<WebKit::ProcessThrottler::Activity<(WebKit::ProcessThrottler::ActivityType)0>> = {get() = 0x0}}
        parameters = <snip here>


Looks like the opensource part of the driver is having trouble with locking? (relevant code below)
    if (!wlMutexInitialized || pthread_mutex_lock(&wlMutex)) {
        assert(!"failed to lock pthread mutex");
        return -1;
    }

One final question before I reassign component: does the crash still occur if you run with the environment variable WEBKIT_FORCE_SANDBOX=0? We just found a sandbox bug that can cause certain syscalls to randomly fail so let's eliminate that potential cause first.

(In reply to Michael Catanzaro from comment #3)
> One final question before I reassign component: does the crash still occur
> if you run with the environment variable WEBKIT_FORCE_SANDBOX=0? We just
> found a sandbox bug that can cause certain syscalls to randomly fail so
> let's eliminate that potential cause first.

Yes, same error.

OK -> egl-wayland for further diagnosis

I have built the latest version

https://bodhi.fedoraproject.org/updates/FEDORA-2020-be2c4beb82

https://koji.fedoraproject.org/koji/buildinfo?buildID=1519004


If it still reproduces after that you will need to upstream

https://github.com/NVIDIA/egl-wayland/issues

Nop, still the same error on the latest version.

Reported upstream.

(In reply to Carlos Mogas da Silva from comment #7)
> Nop, still the same error on the latest version.
> 
> Reported upstream.

Thank you for forwarding the issue upstream, without the debug symbols for libEGL_nvidia.so.0 it is hard to make sense of it.

Upstream bug closed with a fix applied. They didn't version bump, but you can pick the patch up if you want ;)

(In reply to Carlos Mogas da Silva from comment #9)
> Upstream bug closed with a fix applied. They didn't version bump, but you
> can pick the patch up if you want ;)

I have added a comment to the commit

https://github.com/NVIDIA/egl-wayland/commit/9558ec02d0f7bbf30dc1f9ee4c0b06c9b0c49afe

FEDORA-2020-6900d113da has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6900d113da

FEDORA-EPEL-2020-83d4434be7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83d4434be7

FEDORA-2020-fcc03a2706 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-fcc03a2706

FEDORA-2020-fcc03a2706 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-fcc03a2706`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fcc03a2706

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2020-83d4434be7 has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83d4434be7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-6900d113da has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6900d113da`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6900d113da

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-6900d113da has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-fcc03a2706 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-EPEL-2020-83d4434be7 has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.