1811519 - Crash in [@ mozilla::gfx::GfxFormatToSkiaColorType]

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Arturo Mejia [:amejia]]

Crash report: https://crash-stats.mozilla.org/report/index/8b8b42ec-5aeb-44d2-8dba-edb330230120

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(false) (Unknown surface format)

Top 10 frames of crashing thread:

0  libxul.so  mozilla::gfx::GfxFormatToSkiaColorType  gfx/2d/HelpersSkia.h
1  libxul.so  mozilla::gfx::MakeSkiaImageInfo  gfx/2d/HelpersSkia.h:71
1  libxul.so  mozilla::gfx::DrawTargetSkia::Init  gfx/2d/DrawTargetSkia.cpp:1796
2  libxul.so  mozilla::gfx::Factory::CreateDrawTargetForData  gfx/2d/Factory.cpp:444
3  libxul.so  mozilla::widget::AndroidCompositorWidget::StartRemoteDrawingInRegion  widget/android/AndroidCompositorWidget.cpp:66
4  libxul.so  mozilla::wr::RenderCompositorSWGL::AllocateMappedBuffer  gfx/webrender_bindings/RenderCompositorSWGL.cpp:73
4  libxul.so  mozilla::wr::RenderCompositorSWGL::StartCompositing  gfx/webrender_bindings/RenderCompositorSWGL.cpp:186
5  libxul.so  <webrender::compositor::sw_compositor::SwCompositor as webrender::composite::Compositor>::start_compositing  gfx/wr/webrender/src/compositor/sw_compositor.rs:1430
6  libxul.so  webrender::renderer::<impl webrender::composite::CompositeState>::composite_native  gfx/wr/webrender/src/renderer/mod.rs:5717
6  libxul.so  webrender::renderer::Renderer::draw_frame  gfx/wr/webrender/src/renderer/mod.rs:4309

Comment 1

[Chris Peterson [:cpeterson]]

Jamie, jmuizelaar added this MOZ_DIAGNOSTIC_ASSERT(false, "Unknown surface format") eleven months ago (in bug 1755718). Since then, we've received just two crash reports (one from Fenix Nightly 104 and one from 109). But this week, we've received five crash reports from three different installs of Fenix Nightly 110 and 111.

How serious is this "Unknown surface format" error? Did any graphics code change recently that might cause "Unknown surface format" errors?

Comment 2

[Chris Peterson [:cpeterson]]

(In reply to Chris Peterson [:cpeterson] from comment #1)

this week, we've received five crash reports from three different installs of Fenix Nightly 110 and 111.

These five crashes from 110 and 111 are Samsung SM-G960U1 devices. Maybe they're all from one user.

The crashes from 104 and 109 were from a OnePlus LE2123 and Vivo 1935.

Comment 3

[Jamie Nicol [:jnicol]]

Few things to note here:

This is a MOZ_DIAGNOSTIC_ASSERT, so it only crashes on Nightly. On release we just fall back to kRGBA_8888_SkColorType which is probably the best outcome. So not a major concern.

If we look at where this is called from, by process of elimination we can tell that the format is R8G8B8X8 (because R8G8B8A8 is handled in the switch statement). I can see that we handle B8G8R8X8 by falling back to skia's BGRA_8888. Perhaps we want to explicitly do the equivalent for R8G8B8X8 -> RGBA_8888. This is what happens on release channel anyway since the assert isn't enabled.

However, it's a good thing that the assert caught this because the real issue is that we should not be using pure SWGL on Android at all. We should only be using webrender, or SWGL with the OpenGL compositor.

There could be bugs in our fallback logic, of course. But given the very low user count I think it's much more likely that these users have been messing about in about:config. They must have set gfx.webrender.software.opengl to false, otherwise we would be using the OpenGL compositor rather than pure SWGL. I also think they might have set gfx.webrender.fallback.software to false, as the crash reports have "Fallback WR to SW-WR, forced" in the graphicsCriticalError annotation. If that were the default of true we wouldn't need to "force" the fallback.

Perhaps these users were trying to disable fallback to SWGL because they want to remain on hardware acceleration all of the time? We could hardcode it to do the right thing rather than use prefs, but prefs are useful for development. I'm inclined to WONTFIX given the low volume.