1968429 - Crash in [@ nsTArray_Impl<T>::end | nsTArray_Impl<T>::cend | nsAutoTObserverArray<T>::NonObservingRange]

Status: RESOLVED INCOMPLETE

(Core :: Cycle Collector, defect)

Description

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

Crash report: https://crash-stats.mozilla.org/report/index/0ceda412-4e73-47c3-93ad-a76870250519

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_RelocateUsingMemutils>::Length const  xpcom/ds/nsTArray.h:439
0  xul.dll  nsTArray_Impl<mozilla::EventListenerManager::Listener, nsTArrayInfallibleAllocator>::end const  xpcom/ds/nsTArray.h:1286
0  xul.dll  nsTArray_Impl<mozilla::EventListenerManager::Listener, nsTArrayInfallibleAllocator>::cend const  xpcom/ds/nsTArray.h:1288
0  xul.dll  nsAutoTObserverArray<mozilla::EventListenerManager::Listener, 1>::NonObservingRange const  xpcom/ds/nsTObserverArray.h:511
0  xul.dll  mozilla::EventListenerManager::MarkForCC  dom/events/EventListenerManager.cpp:2189
1  xul.dll  mozilla::dom::FragmentOrElement::MarkNodeChildren  dom/base/FragmentOrElement.cpp:1381
1  xul.dll  mozilla::dom::FragmentOrElement::CanSkip  dom/base/FragmentOrElement.cpp:1607
1  xul.dll  mozilla::dom::FragmentOrElement::cycleCollection::CanSkipReal  dom/base/FragmentOrElement.cpp:1740
1  xul.dll  nsCycleCollectionParticipant::CanSkip  xpcom/base/nsCycleCollectionParticipant.h:356
1  xul.dll  RemoveSkippableVisitor::Visit  xpcom/base/nsCycleCollector.cpp:2776

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2025-03-29
• Process type: Multiple distinct types
• Is startup crash: No
• Has user comments: No
• Is null crash: No
• Is use after free crash: Yes - 1 out of 10 crashes happened on or near an allocator poison value

Comment 1

[Andrew McCreight [:mccr8]]

Looks like maybe 10% of these crashes are on the poison value, in the last 6 months. I'm not sure how actionable this is.

Comment 2

[Gabriele Svelto [:gsvelto]]

Lots of potential bit-flips here. This seems like a great candidate for our new memory testing infrastructure. We don't have the data indexed in crash-stats yet (see bug 1948941), but once we do we might be able to verify how many of these potential bit-flips are happening on faulty machines.

Comment 3

[Andrew McCreight [:mccr8]]

Good catch. Yeah, this looks very junky. Let's just close it. Olli and I looked at some crash reports and couldn't figure anything out.