Open Bug 1408351 Opened 7 years ago Updated 2 years ago

Stylo: Crash in style::invalidation::stylesheets::StylesheetInvalidationSet::scan_component

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Version:
58 Branch
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox56 --- unaffected
firefox57 --- unaffected
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- fix-optional

People

(Reporter: calixte, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, nightly-community, regression, Whiteboard: [clouseau])

Crash Data

This bug was filed from the Socorro interface and is report bp-db5de08a-2aec-44d0-b7c0-daf530171013. ============================================================= There are 2 crashes in nightly 58 from the same installation. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1407522. [1] https://hg.mozilla.org/mozilla-central/rev?node=dd04bc03bb5ef42e178e9ecaeb202f78281f0f26
Flags: needinfo?(cam)
Manish, any opinion on this one? This really makes me suspect even more that the similar bugs we're chasing down on HashMap are really related to the HeaderSlice / SelectorBuilder stuff.
Flags: needinfo?(manishearth)
The hashmap bugs are in code that's not always near usages of HeaderSlice, though. But it's still possible; idk. I don't really have an opinion on this crash (worth looking into HeaderSlice though)
Flags: needinfo?(manishearth)
Priority: -- → P3
Given P3 and super low crash volume, let's mark as fix-optional for 58.
status-firefox58: affected → fix-optional
Still showing up in low volume, on the 3-14 Nightly. bp-13d8be3f-b504-4869-bc8e-364a70180315
Curiously, ~82% of the crashes are from 32-bit Firefox, even though ~68% of Firefox users are now running 64-bit Firefox. We have crash reports from Windows and macOS, but not Linux.
Crash Signature: [@ style::invalidation::stylesheets::StylesheetInvalidationSet::scan_component] → [@ style::invalidation::stylesheets::StylesheetInvalidationSet::scan_component] [@ style::invalidation::stylesheets::{{impl}}::scan_component] [@ static void style::invalidation::stylesheets::StylesheetInvalidationSet::scan_component]
status-firefox59: ? → wontfix
status-firefox60: --- → affected
status-firefox61: --- → affected
Flags: needinfo?(cam)
Updating tracking flags as I see a few of these crashes in 64 nightly triage.
status-firefox63: --- → affected
status-firefox64: --- → affected
Too late to fix in 63. We could still take a patch for 65 and potentially for 64.
status-firefox63: affected → wontfix
status-firefox64: affected → fix-optional

Trevor, please don't reset status flags on old bugs unless something's changed or someone's going to be working on them, it doesn't help anything.

status-firefox64: fix-optional → wontfix
status-firefox67: --- → wontfix
status-firefox68: affected → wontfix
status-firefox69: affected → fix-optional

What this bug really needs is a way to reproduce it. We have no hint on what can be the root cause of this bug otherwise.

We've seen some similar crashes that are highly correlated with a CPU model for example, or crashes that contain bitflips on the binaries due to bad ram on bad disk. If you have any way to reproduce this or any data that could help us fix this, I'd happily investigate further. The minidumps and crash reports don't hint any correlation that seems obvious to me.

That being said, the last stack is interesting and hints at some addon or chrome code running JS at a bad time. That still shouldn't crash. https://crash-stats.mozilla.org/report/index/3e948d7f-1056-4dc1-8dd5-11de50190612

Anyhow, given there are 15 crashes on the latest 9 releases of firefox, and that we don't have any lead as to how to reproduce it, it seems wasteful to spend engineering time on this bug when there are more important reproducible bugs that we can spend our time on.

QA Whiteboard: qa-not-actionable
Severity: critical → S2

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3
You need to log in before you can comment on or make changes to this bug.