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

Status: RESOLVED FIXED

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

Description

[Sotaro Ikeda [:sotaro]]

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

Comment 1

[Glenn Watson [:gw]]

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

Comment 2

[Glenn Watson [:gw]]

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.

Comment 3

[Sotaro Ikeda [:sotaro]]

(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

Comment 4

[Glenn Watson [:gw]]

Attachment: Bug 1600501 - Fix intermittent compositor surface creation bug.

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.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/504dfff094f5
Fix intermittent compositor surface creation bug. r=nical

Comment 6

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/504dfff094f5