Open Bug 1705611 Opened 8 months ago Updated 7 months ago

Crash in [@]


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

Firefox 87




(Reporter: yoasif, Assigned: jnicol)


(Blocks 1 open bug)


(Keywords: crash)

Crash Data

Filed from

533 crashes in the last week.

Most of the crashes seem to be from moto g(6)

Crash report:


Top 10 frames of crashing thread:

6 <gleam::gl::GlesFns as gleam::gl::Gl>::bind_renderbuffer third_party/rust/gleam/src/
7 webrender::device::gl::Device::bind_draw_target gfx/wr/webrender/src/device/
8 webrender::renderer::Renderer::draw_frame gfx/wr/webrender/src/renderer/
9 webrender::renderer::Renderer::render_impl gfx/wr/webrender/src/renderer/
Component: General → Graphics: WebRender
Product: GeckoView → Core
Flags: needinfo?(jnicol)

Looking at the proto signatures, they mainly seem to be

a) bind_draw_target() | glBindRenderbuffer (Maybe the same as bug 1704153)
or b) glCopyImageSubData (I think we only call this when resizing the GPU cache on adreno, but the stacks aren't helpful)

Interestingly we never call glBindRenderbuffer from bind_draw_target().. Perhaps it's actually glBindFramebuffer that is crashing (it's declared just afterwards in gleam, so maybe a similar address). There's also some glLineWidth calls in some of the proto signatures, and I'm pretty certain we never ever call that. So take android crash stacks with a pinch of salt!

About a 3rd of the reports have PBO mapping failures or surface allocation errors in the graphicsCriticalError. So potentially OOM related, though not smoking gun levels.

Unfortunately not a lot to go on yet. Hopefully another user will come forward with some reliable steps to reproduce.

Flags: needinfo?(jnicol)
See Also: → 1704153

Oh, on my moto g6 I've been able to reproduce on (from bug 1680999). Open the page and then it quickly starts to spew warning about allocation failures while the screen is blank. Pan or zoom on the blank screen just to cause it some more grief and it sometimes crashes with this signature.

Both of my crashes have the stack Renderer::draw_frame() | Device::invalidate_render_target() | mdb_env_cthr_toggle | then several

We do call glBindFramebuffer (not glBindRenderbuffer) from invaldiate_render_target.

Local crash stack from an opt gecko + debug fenix build:

#00 pc 0013f9d0  /vendor/lib/egl/ (EsxRenderBucket::AddUnbucketedEntries(EsxCmdBufType, unsigned int)+132)
#01 pc 0013ef47  /vendor/lib/egl/ (EsxRenderBucket::BucketRenderingCmds(EsxRenderBucketParams*)+740)
#02 pc 00172e9d  /vendor/lib/egl/ (EsxContext::BucketRenderingCmds(int)+712)
#03 pc 000d2de7  /vendor/lib/egl/ (EsxContext::BindDrawFramebuffer(EsxFramebufferObject*)+178)
#04 pc 000a2e81  /vendor/lib/egl/ (EsxContext::GlBindFramebuffer(unsigned int, unsigned int)+272)
#05 pc 05546947  /data/app/org.mozilla.fenix.debug-g_KH-CBBeQT6pqI1ITjB4A==/lib/arm/ (offset 0x269a000) (webrender::device::gl::Device::link_program::h1861562ffbe726a6+70)
#06 pc 0556eaf3  /data/app/org.mozilla.fenix.debug-g_KH-CBBeQT6pqI1ITjB4A==/lib/arm/ (offset 0x269a000)
#07 pc 05567b9f  /data/app/org.mozilla.fenix.debug-g_KH-CBBeQT6pqI1ITjB4A==/lib/arm/ (offset 0x269a000) (webrender::renderer::Renderer::update::h66f1424ff0cfdacb+5022)
#08 pc 055672cb  /data/app/org.mozilla.fenix.debug-g_KH-CBBeQT6pqI1ITjB4A==/lib/arm/ (offset 0x269a000) (webrender::renderer::Renderer::update::h66f1424ff0cfdacb+2762)

Again, Device::link_program() does not call glBindFramebuffer, so I wouldn't trust the libxul symbols here. But at this point I'm fairly certain this is a crash in glBindFramebuffer.

Assignee: nobody → jnicol
Severity: -- → S3
Priority: -- → P3
See Also: → 1710684
You need to log in before you can comment on or make changes to this bug.