1466945 - Crash in mozilla::Span<T>::Subspan (from RetainedDisplayListBuilder::MergeDisplayLists)

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect, P2)

Description

[Mats Palmgren (inactive)]

This bug was filed from the Socorro interface and is
report bp-612cbac0-1af0-4e26-8758-c35fb0180605.
=============================================================

MOZ_CRASH Reason:  MOZ_RELEASE_ASSERT(aStart <= len && (aLength == dynamic_extent || (aStart + aLength <= len)))


Top 10 frames of crashing thread:

0 xul.dll mozilla::Span<Index<OldListUnits>, 4294967295>::Subspan mfbt/Span.h:704
1 xul.dll DirectedAcyclicGraph<OldListUnits>::GetDirectPredecessors layout/painting/RetainedDisplayListHelpers.h:128
2 xul.dll MergeState::Finalize layout/painting/RetainedDisplayListBuilder.cpp:322
3 xul.dll RetainedDisplayListBuilder::MergeDisplayLists layout/painting/RetainedDisplayListBuilder.cpp:517
4 xul.dll MergeState::ProcessItemFromNewList layout/painting/RetainedDisplayListBuilder.cpp:293
5 xul.dll nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity<nsTArrayInfallibleAllocator> xpcom/ds/nsTArray-inl.h:136
6 xul.dll RetainedDisplayListBuilder::MergeDisplayLists layout/painting/RetainedDisplayListBuilder.cpp:514
7 xul.dll RetainedDisplayListBuilder::AttemptPartialUpdate layout/painting/RetainedDisplayListBuilder.cpp:1206
8 xul.dll nsIFrame::GetBorderRadii layout/generic/nsFrame.cpp:1828
9 xul.dll nsTArray_Impl<imgCacheEntry*, nsTArrayInfallibleAllocator>::AppendElement<imgCacheEntry*&, nsTArrayInfallibleAllocator> xpcom/ds/nsTArray.h:2288

=============================================================

Comment 1

[Matt Woodrow (:mattwoodrow)]

This is a fun one. Setting blocking RDLBugs since it's from RDL code, but I suspect it's not really related.

Had a look at some crash reports:

* len=7, aStart=3, aLength=0x00440001
* len=1, aStart=0, aLength=0x00700000
* len=1, aStart=0x08000000, aLength=1
* len=8, aStart=7, aLength=0x00000401
* len=79, aStart=0x0000023a, aLength=1
* len=1, aStart=0, aLength=0x00800000

The invalid number isn't consistently the same one, and they don't look like off-by-one, miscounting or overflow bugs. They look very much look the expected number, with a high bit or two flipped.

This seems like a symptom of corruption, but hard to know where it would be coming from. We have existing bugs on corruption happening during DL building though.

The pattern of corruption (bit flipping), and that it appears to be different bits every time probably is useful information, though I can't think of anything that would match that right now.

Comment 3

[Timothy Nikkel (:tnikkel)]

Not many crashes on crash stats -> S3.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.