This bug is for crash report bp-fc095833-f318-422b-a4c2-49c7d0200320.

Top 10 frames of crashing thread:

0 libxul.so InvalidArrayIndex_CRASH xpcom/ds/nsTArray.cpp:27
1 libxul.so mozilla::layers::DisplayItemCache::MarkSlotOccupied gfx/layers/wr/DisplayItemCache.cpp:109
2 libxul.so mozilla::wr::DisplayListBuilder::FinishGroup gfx/webrender_bindings/WebRenderAPI.cpp:1501
3 libxul.so nsDisplayCompositorHitTestInfo::CreateWebRenderCommands layout/painting/nsDisplayList.cpp:5550
4 libxul.so mozilla::layers::WebRenderCommandBuilder::CreateWebRenderCommands gfx/layers/wr/WebRenderCommandBuilder.cpp:1700
5 libxul.so mozilla::layers::WebRenderCommandBuilder::CreateWebRenderCommandsFromDisplayList gfx/layers/wr/WebRenderCommandBuilder.cpp:1809
6 libxul.so mozilla::layers::WebRenderCommandBuilder::BuildWebRenderCommands gfx/layers/wr/WebRenderCommandBuilder.cpp:1634
7 libxul.so mozilla::layers::WebRenderLayerManager::EndTransactionWithoutLayer gfx/layers/wr/WebRenderLayerManager.cpp:352
8 libxul.so nsDisplayList::PaintRoot layout/painting/nsDisplayList.cpp:3037
9 libxul.so nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:4099

There are 22 crashes (from 22 installations) in nightly 76 starting with buildid 20200319094444. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1614655.
The moz_crash_reason is always ElementAt(aIndex = [0-9]+, aLength = 1024).

[1] https://hg.mozilla.org/mozilla-central/rev?node=aaed31bbe8f4

I think this is a problem with reinitialized WebRenderLayerManager receiving the previous display list that includes cached display items. Since the cache size has been reset to 1024, trying to reuse any items that got assigned a slot higher than that, will hit the out of bounds assertion.

I managed to reproduce this by forcing a device reset on Windows 10 while running display list mutate test. This gave me the same crash signature1. Fixing this should be relatively straightforward: either we copy the previous cache when changing WebRenderLayerManager, or clear the cache state from the items.

This is needed because display lists and DisplayItemCache have different lifetimes. For example, display lists can outlive WebRenderLayerManager when device reset occurs.

A slightly nicer way of fixing this would be to couple DisplayItemCache with nsDisplayList or nsDisplayListBuilder. This is would currently require a lot of refactoring to look nice, because the painting code still supports non-retained display lists and non-WR code paths.

https://hg.mozilla.org/mozilla-central/rev/f215196f1d1c