Closed Bug 1600501 Opened 3 months ago Closed 3 months ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla73
Tracking Status
firefox73 --- fixed

People

(Reporter: sotaro, Assigned: gw)

References

Details

Attachments

(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
https://treeherder.mozilla.org/#/jobs?repo=try&author=sikeda.birchill%40mozilla.com&selectedJob=278874098

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.

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=7a3d87923f2d86b68132334f0c7db510999a76a5&selectedJob=278987650
[2] https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=278987653&repo=try&lineNumber=3902
[3] https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=278987650&repo=try&lineNumber=4607

Priority: -- → P3
Assignee: nobody → gwatson

It seems like this may not be occurring on current m-c?

https://treeherder.mozilla.org/#/jobs?repo=try&revision=85b6f6f046c351a7b764e497b67ae8cf868af1e7 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?

https://treeherder.mozilla.org/#/jobs?repo=try&revision=85b6f6f046c351a7b764e497b67ae8cf868af1e7 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.

https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=279472362&revision=3a5cea30145a9b720fa2b20352d999e97e610651

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
occur.

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 gwatson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/504dfff094f5
Fix intermittent compositor surface creation bug. r=nical
Status: NEW → RESOLVED
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.