Created attachment 300323 [details] BT from gdb for the WebProcess (forced) Epiphany 3.22.5 and WebKit 2.15.4 I'm running Epiphany with the dconf key: "process-model" = "shared-secondary-process" And the env variable: "export LIBGL_DRI3_DISABLE=1" The compilation was done with CMake args: '-DPORT=GTK -DCMAKE_BUILD_TYPE=Release -DENABLE_MINIBROWSER=ON -DCMAKE_C_FLAGS_RELEASE="-O0 -g -DNDEBUG -DG_DEBUG=fatal-criticals -DG_DISABLE_CAST_CHECKS" -DCMAKE_CXX_FLAGS_RELEASE="-O0 -g -DNDEBUG -DG_DEBUG=fatal-criticals -DG_DISABLE_CAST_CHECKS"' After visiting several pages, eventually, my last opened tabs won't finish loading and rendering the page. The tab shows the loading progress but never gets to finish. Trying to reload or stop and reload won't help. Also, the rest of the tabs are in an unresponsive state. There is no SIGSEV nor the desktop gets a high load but, although ehy is not frozen, the tabs content seems to be. This bug is not reproducible in a predictable way.
Created attachment 300405 [details] Another BT from gdb for the WebProcess (forced) Maybe I should open a different bug since this looks different in the BT, but the experience is quite similar. In this case, I opened a YouTube video. I couldn't see the image but listened to the audio. When I closed the tab, the audio stopped, but the rest of the tabs seems stalled, without re-painting/re-loading. Ephy was responsive, however. This was running *without*: "export LIBGL_DRI3_DISABLE=1"
Yes, it's again _mesa_Clear blocking our compositing thread.
*** Bug 166924 has been marked as a duplicate of this bug. ***
So it was actually useful that Andres posted two backtraces, one with DRI3 and one without. According to Miguel (see his comment in bug #166924), this seems to be two different mesa bugs that exhibit the same symptom: https://bugs.freedesktop.org/show_bug.cgi?id=84252 for the DRI3 case and https://bugs.freedesktop.org/show_bug.cgi?id=94108 for the DRI2 case. He thinks that we do not need to change anything in WebKit, so I'm closing this bug. (Note: this is a valid bug report, but WebKit Bugzilla does not have any appropriate resolution for a bug that turns out to be in one of our dependencies, hence I choose the INVALID resolution.)