Closed Bug 1600501 Opened 3 months ago Closed 3 months ago

Intermittent assertion failure: it != mDCLayers.end() with os compositor on Windows


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




Tracking Status
firefox73 --- fixed


(Reporter: sotaro, Assigned: gw)




(1 file)

During testing by enabling os compositor, there were occasional assert failuress.

Assertion failure: it != mDCLayers.end(), at z:/build/build/src/gfx/webrender_bindings/DCLayerTree.cpp:206

Blocks: 1592509

I did a try run [1] that showed the failure in [2] and [3].

From the log files, both asserts occur immediately after new firefox processes are spawned.

It seems there might be a race condition during startup - where somehow the surfaces are bound but haven't been created. I haven't reproduced locally yet, so I'm not sure if it's an issue inside Gecko or WR.


Priority: -- → P3
Assignee: nobody → gwatson

It seems like this may not be occurring on current m-c? still has some pending jobs, but it doesn't seem to have occurred yet.

Flags: needinfo?(sotaro.ikeda.g)

(In reply to Glenn Watson [:gw] from comment #2)

It seems like this may not be occurring on current m-c? still has some pending jobs, but it doesn't seem to have occurred yet.

The problem still happened, the above link has the assert failure. I also triggered try this morning with os compositor. It also caused the assert failure, though it seemed less frequent.

Flags: needinfo?(sotaro.ikeda.g)

With the native compositor enabled, try runs were occasionally
hitting an assertion failure where a compositor surface was
being drawn, but hadn't been created (so the id was unknown).

This was occurring when the MemoryPressure event occurs in some
situations during shutdown. When this occurs, the active_documents
list is cleared. This could result in the native surface updates
list (which was stored in the Frame of a Document) not being
applied, meaning the new surface was not created. If a subsequent
frame then tried to composite that surface, this assert would

This is fixed by moving compositor surface management to be handled
via the resource cache, in the same way as texture cache updates.

This ensures that even in the presence of a memory pressure event,
any pending native surface updates are applied to the renderer.

Pushed by
Fix intermittent compositor surface creation bug. r=nical
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla73
You need to log in before you can comment on or make changes to this bug.