Open Bug 1645841 Opened 5 months ago Updated 7 days ago

Crash in [@ core::option::expect_failed | webrender_api::resources::ApiResources::update_blob_image]


(Core :: Graphics: WebRender, defect)




Tracking Status
firefox82 --- affected
firefox83 --- affected
firefox84 --- affected
firefox85 --- affected


(Reporter: agi, Unassigned, NeedInfo)


(Blocks 1 open bug)


(Keywords: crash, Whiteboard: [geckoview])

Crash Data

We're seeing this but when opening a WebExtension page on Fenix

This bug is for crash report bp-7be62153-139b-46e1-b058-0ac310200615.

Top 10 frames of crashing thread:

0 RustMozCrash mozglue/static/rust/wrappers.cpp:17
1 mozglue_static::panic_hook mozglue/static/rust/
2 core::ops::function::Fn::call src/libcore/ops/
3 std::panicking::rust_panic_with_hook src/libstd/
4 rust_begin_unwind src/libstd/
5 core::panicking::panic_fmt src/libcore/
6 core::option::expect_failed src/libcore/
7 webrender_api::resources::ApiResources::update_blob_image gfx/wr/webrender_api/src/
8 webrender_api::resources::ApiResources::update gfx/wr/webrender_api/src/
9 wr_api_send_transaction gfx/wr/webrender_api/src/
Whiteboard: [geckoview]

I have been unable to reproduce this on my Pixel 2 (Android 9 and 10), OnePlus 6 (Android 10), or Moto G7 Play (Android 9).

Blocking wr-adreno5xx6xx even though this is unlikely device specific, because we will want to fix it before shipping to more devices.

I'll ask on the github ticket whether the reporter could try a custom build with some logging added.

Severity: -- → S2

I got a new phone (a OnePlus 8 Pro) and am now able to reproduce this. Very easily on the official Fenix build, and frustratingly less often on a local build with logging.

A key thing I noticed in my logcat just before the crash is:

[GFX1-]: DataSourceSurface of SharedSurfaces does not exist for extId:8589934603

I see this is also present in all the crash reports. If this warning is logged, then WebRenderBridgeParent::AddSharedExternalImage() will return false, and WebRenderBridgeParent::UpdateResources() will return early. If there were some AddBlobImage commands in the resource list after the AddSharedExternalImage command which fails, then they will not be processed. Then, if in the next display list there are some SetBlobImageVisibleArea commands which refer to those blob images, we will hit this assertion.

So the question is, why does the call to SharedSurfacesParent::Acquire() fail? From adding some logging, I can see that SharedSurfacesParent::RemoveSameProcess() is being called a couple of milliseconds before the call to Acquire(), from a different thread. I will continue looking in to why this is happening, but it's unfamiliar code. Any ideas, Andrew?

Flags: needinfo?(aosmond)
Blocks: wr-80
No longer blocks: wr-80
Blocks: wr-81
Blocks: gfx-82
No longer blocks: wr-81

Removing from 82 since this tracks wr-adreno5xx6xx. Doesn't look too serious based on crash rate.

No longer blocks: gfx-82
Crash Signature: [@ core::option::expect_failed | webrender_api::resources::ApiResources::update_blob_image] → [@ core::option::expect_failed | webrender_api::resources::ApiResources::update_blob_image] [@ core::option::expect_failed | webrender::api::resources::ApiResources::update_blob_image]
Crash Signature: [@ core::option::expect_failed | webrender_api::resources::ApiResources::update_blob_image] [@ core::option::expect_failed | webrender::api::resources::ApiResources::update_blob_image] → [@ core::option::expect_failed | webrender_api::resources::ApiResources::update_blob_image] [@ core::option::expect_failed | webrender::api_resources::ApiResources::update_blob_image]

This crash also affects Windows, macOS, and Linux. Fortunately, the crash volume is very low.


OS: Android → All
Hardware: Unspecified → All
You need to log in before you can comment on or make changes to this bug.