This bug is for crash report bp-a304b57e-dfb5-4f58-8ba0-9666a0200705.

Top 10 frames of crashing thread:

0 libxul.so DMABufSurfaceYUV::CreateTexture widget/gtk/DMABufSurface.cpp:964
1 libxul.so mozilla::wr::RenderDMABUFTextureHostOGL::Lock gfx/webrender_bindings/RenderDMABUFTextureHostOGL.cpp:53
2 libxul.so mozilla::wr::wr_renderer_lock_external_image gfx/webrender_bindings/RendererOGL.cpp:36
3 libxul.so <webrender_bindings::bindings::WrExternalImageHandler as webrender_api::image::ExternalImageHandler>::lock gfx/webrender_bindings/src/bindings.rs:416
4 libxul.so webrender::renderer::Renderer::render_impl gfx/wr/webrender/src/renderer.rs:5711
5 libxul.so webrender::renderer::Renderer::render gfx/wr/webrender/src/renderer.rs:3255
6 libxul.so wr_renderer_render gfx/webrender_bindings/src/bindings.rs:606
7 libxul.so mozilla::wr::RendererOGL::UpdateAndRender gfx/webrender_bindings/RendererOGL.cpp:142
8 libxul.so mozilla::wr::RenderThread::UpdateAndRender gfx/webrender_bindings/RenderThread.cpp:478
9 libxul.so mozilla::wr::RenderThread::HandleFrameOneDoc gfx/webrender_bindings/RenderThread.cpp:356

High-volume NULL pointer access that started with buildid 20200703215022. Just looking at the code it's unclear what's NULL here since all the pointers involved seem to be either NULL-checked or should have caused a crash earlier if they were NULL. But maybe I'm missing something since I'm not familiar with this code.

I'm getting this with EGL + VAAPI + H264 (I'm not quite sure about H264 though). And without EGL I get bug 1650520.

Something on my side seemed to be wrong, or something has just changed with a new version.

With 80.0a1 (2020-07-07) this crash now happens to me when without EGL + VAAPI and I've got gdb running, and see that egl, aka mozilla::gl::GLLibraryEGL::sEGLLibrary is null. It seems that EGL code still executes somehow when EGL isn't enabled.

All the crash reports are from Linux.

This looks more like a WebRender graphics issue than something GTK specific, so I'm moving it over.

Regression window: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2da2c9f85102b92961435e5434f469fef0ebf08c&tochange=efa2336315eda0aaf78c2e94d6c9c98106ea136b

Sounds like this could've been bug 1619523.

This crash happens when enabling VAAPI while using GLX.
bp-01571c61-3dc9-42a8-aca8-f52e70200710

MOZ_X11_EGL=1 environment variable is required on X11. If someone has multiple GPUs, but wants to use the dedicated one, set MOZ_WAYLAND_DRM_DEVICE=/dev/dri/renderD129 until bug 1588904 has been fixed. With MOZ_LOG="PlatformDecoderModule:5" one can check whether VAAPI is used or not.

This is one of our top crashes on Linux. However, we are getting bailed out by the fact it is in the GPU process. We want to disable the GPU process, because of bugs blocking bug 1653444 (I assume there will be more over time), but I don't think I can do that until this is fixed, or we block WebRender with Wayland on nightly for the time being (not a big deal, we are focused on shipping X11 + WebRender right now).

Oh, I spoke too soon. I thought this was when Wayland was in issue, but the crashes suggest not. Okay, that's more important for us to fix asap :).

This crash happens only on X11 if you enable media.ffmpeg.vaapi* without setting MOZ_X11_EGL=1 env var.
If you merge bug 1653443 this will instantly crash Firefox when loading a video:
mozregression --launch 2020-07-19 --pref gfx.webrender.all:true media.ffmpeg.vaapi.enabled:true media.ffmpeg.vaapi-drm-display.enabled:true layers.gpu-process.enabled:false -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605

Sounds like are missing a check for whether we are on GLX when doing anything DMABUF related.

I'll put together a patch to disable it without that envvar. Thanks everyone!

WebGL has this check:
https://searchfox.org/mozilla-central/rev/9b282b34b5aa0f836beb735656c55efb2cc4c617/gfx/gl/SharedSurface.cpp#111

gl.GetContextType() == GLContextType::EGL

https://hg.mozilla.org/mozilla-central/rev/fe7075f48cf0