1863178 - Crash in [@ mozilla::dom::ComputeTheIntersection]

Status: NEW

(Core :: Layout, defect)

Description

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

Crash report: https://crash-stats.mozilla.org/report/index/247265e2-2114-4cbf-b75e-b224b0231030

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  mozilla::dom::ComputeTheIntersection  dom/base/DOMIntersectionObserver.cpp:396
0  xul.dll  mozilla::dom::DOMIntersectionObserver::Intersect  dom/base/DOMIntersectionObserver.cpp:714
1  xul.dll  mozilla::dom::DOMIntersectionObserver::Update  dom/base/DOMIntersectionObserver.cpp:752
1  xul.dll  mozilla::dom::Document::UpdateIntersectionObservations  dom/base/Document.cpp:16368
1  xul.dll  nsRefreshDriver::UpdateIntersectionObservations  layout/base/nsRefreshDriver.cpp:2195
1  xul.dll  nsRefreshDriver::Tick  layout/base/nsRefreshDriver.cpp:2747
2  xul.dll  mozilla::RefreshDriverTimer::TickDriver  layout/base/nsRefreshDriver.cpp:362
2  xul.dll  mozilla::RefreshDriverTimer::TickRefreshDrivers  layout/base/nsRefreshDriver.cpp:340
3  xul.dll  mozilla::RefreshDriverTimer::Tick  layout/base/nsRefreshDriver.cpp:356
4  xul.dll  mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers  layout/base/nsRefreshDriver.cpp:923

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

• First crash report: 2023-10-10
• Process type: Content
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - 1 out of 4 crashes happened on null or near null memory address

By analyzing the backtrace, the regression may have been introduced by a patch [1] to fix Bug 1861259.

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

:dholbert, since you are the author of the potential regressor, could you please take a look?

Comment 1

[Daniel Holbert [:dholbert]]

It's possible I'm missing something, but at first glance it looks like this is the bot mis-firing and there's no actual regression here.

We've had roughly the same low volume of crashes with this signature going back for as far as we've got data (there was a spike in September, but we're past that).

I think the signal that the bot was picking up on was four crashes on Nightly within a single month, which is somewhat interesting (particularly since we haven't had any crashes with this signature on Nightly before that). But to the extent that that's a real signal, that means the bot's assignment of a potential regressor is off by a few weeks. The supposed potential-regressor, bug 1861259, landed on Oct 26 (and also should be a no-behavior-change patch stack), and the first Nightly crash here was on Oct 10th, over two weeks earlier.

Comment 2

[Daniel Holbert [:dholbert]]

Hence, removing regression keyword and invalid potential-regressor-bug. Let's keep an eye on crash volume for 120 beta, though (since the first Nightly crashes were in 120). If there were a real regression, we'd expect to see some increased volume there; but fortunately there are zero crashes for 120 beta so far.

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #1)

The supposed potential-regressor, bug 1861259, landed on Oct 26 (and also should be a no-behavior-change patch stack), and the first Nightly crash here was on Oct 10th, over two weeks earlier.

I filed bug 1863189 on seeing if we can make the bot smarter in light of this^ sort of temporal anomaly where it identifies a regressor that landed after the start of the signal.

Having said that: the first two Nightly crashes here are probably ignorable -- those two (bp-029a34de-ca3f-4d64-b0eb-d3e320231010 and bp-7a87ed27-76a1-4448-a50f-2e32f0231011) look like they were probably the same user (based on OS/hardware in the crash report), and they both show Possible bit flips max confidence values that are quite high (66%, 73%). So I suspect those two are bit-flips or something hardware-specific for that particular user. So: after setting those aside, the signal here (if there is a signal) would actually be the two Nightly 121 crashes that are in fact after the supposed-regressor, bp-247265e2-2114-4cbf-b75e-b224b0231030 and bp-67f9380b-37de-4667-a0f3-c15ee0231104.

But I still think this remaining signal is just noise; but, worth keeping an eye on to be sure.

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #3)

But I still think this remaining signal is just noise; but, worth keeping an eye on to be sure.

Circling back: there are no new nightly crashes since the ones referenced in the comments above, so I don't think there's any actual regression or anything particularly interesting here; this very-low-level-crasher could just be a symptom of a bit flip or other bad hardware.

I don't think it's useful to track version-specific "affected" flags for bugs that have been around ~forever-as-far-as-we-can-tell (as this one has, based on the limited crash data that we have, going back 6 months), so I'll clear the status-firefox120 field. And I think we can consider this S4 due to crash volume and potential for bad-hardware-involvement.