1726792 - Crash in [mozilla::wr::RenderThread::Resume(mozilla::wr::WrWindowId)]

Status: RESOLVED DUPLICATE of bug 1747116

(Core :: Graphics: WebRender, defect, P3)

Description

[Arturo Mejia [:amejia]]

We noticed some reports in crash stats https://crash-stats.mozilla.org/signature/?product=Fenix&signature=libandroid.so%400x155b9&version=93.0a1&date=%3C2021-08-20T14%3A22%3A46%2B00%3A00&date=%3E%3D2021-08-13T14%3A22%3A46%2B00%3A00

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

All chromebook devices. This website has a list of Chromebooks that use the Google Octopus board, https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices they all use Intel's Gemini Lake SOC with UHD Graphics 600 https://en.wikichip.org/wiki/intel/cores/gemini_lake

Comment 2

[Sotaro Ikeda [:sotaro]]

Almost all crashes had the following GraphicsCriticalError log. It might be related to the problem.

|[0][GFX1-]: Failed to compile vertex shader: composite_TEXTURE_EXTERNAL
0:40(13): error: no matching function for call to `textureSize(samplerExternalOES, int)'; candidates are:

Comment 3

[Sotaro Ikeda [:sotaro]]

:jnicol, can you comment to the bug?

Comment 4

[Jamie Nicol [:jnicol]]

The error message indicates that the device claims to support GL_OES_EGL_image_external_essl3 but is buggy. As a result it presumably always fails when attempting to render video. We could try using the ESSL1 GL_OES_EGL_image_external path instead, which hopefully it does indeed support properly.

But I'm not sure that explains the crash, and there are a number of crashes without the error message. I guess given it occurs in libandroid.so, that this is to do with the ANativeWindow function calls in RenderCompositorEGL::Resume(). We could start by adding a null check to the ANativeWindow_fromSurface() call. But we do expect that to succeed, and I worry we could then silently be falling back to swgl and hiding athe underlying bug.

Comment 5

[Jamie Nicol [:jnicol]]

Nical, can you reproduce this on your chromebook device?

Can you also please check in about:support whether the extensions GL_OES_EGL_image_external and GL_OES_EGL_image_external_essl3 are supported? And whether playing a video works correctly, or falls back to swgl gracefully, or maybe even triggers this crash?

Comment 6

[Nicolas Silva [:nical]]

I watched a video on youtube, another one on vimeo and an h264 .mp4 sample without reproducing the bug on the chromebook.

In about:config I see both GL_OES_EGL_image_external and GL_OES_EGL_image_external_essl3.

Edit: Sorry, I was running without webrender somehow. With webrender enabled, It works well on youtube and the h264 sample but vimeo freezes, eand eventually I get this crash https://crash-stats.mozilla.org/report/index/44bfd980-10cb-4da8-b4ff-e72cb0210830 in which we try to fall back to GL layers but we don't get a GL context. and assert. there is ][GFX1-]: Failed to load a program object with a program binary: gpu_cache_update renderer Mesa DRI Intel(R) UHD Graphics 600 (Geminilake 2x6) (t=1.65132) |[46][GFX1]: Error in eglSetDamageRegion: 0x3002 (t=197.242) |[47][GFX1-]: Failed to compile vertex shader: composite_TEXTURE_EXTERNAL in the gfx critical log.

Comment 7

[Jamie Nicol [:jnicol]]

Interesting! It is curious that some videos work and others do not. If the ESSL3 extension was buggy I'd expect shader compilation to always fail. Maybe it fails in the composite shader but not brush_image, and therefore whether the video plays okay depends upon whether we can directly composite it or not.

The crash is bug 1532456. That crash has stopped occurring since firefox 92. But I wonder if it has been replaced by this one as both occur during fall back. I notice the build ID in your crash report is very old - could you try again after updating nightly?

Comment 8

[Nicolas Silva [:nical]]

After update none of the 3 test cases work.
Some of the time it will freeze for a few second and crash, some of the time it will freeze without crashing, but not play the video and after that switching to another tab such as about:support crahes.
I gracefully fell back to SWGL once out of the dozen attempts.

The crash reports contain RenderThread::resume like https://crash-stats.mozilla.org/report/index/4dfc1234-037a-45a4-85a3-42ccc0210901

Comment 9

[Jamie Nicol [:jnicol]]

Hmm, I no longer seem to be able to reproduce this crash. I can still reproduce the shader compilation error when playing video, but no it falls back relatively gracefully to SWGL rather than crashing.

However, crash stats indicate people still are encountering this in the wild. And not all crash reports for this signature are because of the shader compilation error.

So I'll fix the shader compilation error in bug 1733919, and we'll leave this open for now while I investigate further

Comment 10

[Jamie Nicol [:jnicol]]

This was fixed by bug 1747116