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

Status: RESOLVED WORKSFORME

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

Description

[Calixte Denizet (:calixte)]

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

Comment 1

[Emilio Cobos Álvarez (:emilio)]

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.

Comment 2

[Manish Goregaokar [: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)

Comment 3

[Mike Taylor [:miketaylr]]

Given P3 and super low crash volume, let's mark as fix-optional for 58.

Comment 4

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals

Comment 5

[Andrew McCreight [:mccr8]]

Still showing up in low volume, on the 3-14 Nightly. bp-13d8be3f-b504-4869-bc8e-364a70180315

Comment 6

[Chris Peterson [:cpeterson]]

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.

Comment 7

[Marcia Knous [:marcia]]

Updating tracking flags as I see a few of these crashes in 64 nightly triage.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix in 63. We could still take a patch for 65 and potentially for 64.

Comment 9

[Julien Cristau [:jcristau]]

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.

Comment 10

[Trevor Skywalker]

(In reply to Julien Cristau [:jcristau] from comment #9)

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.

You know what. Firefox is BROKEN! There is NO stable version. Every version is really an experiment.

After observing the way that you process and troubleshoot bugs I have very little faith in Mozilla as an organization and Firefox as a product. I do not think that any other organization that values and requires stability in a product should use Firefox. Any organizations such as governments or businesses that depend on products to be safe, secure, effective, and without BUGS would be putting the integrity of their organization in jeopardy by using your products. Even your Long-Term, Extended Support Release (ESR) versions are never really stable and secure. The ESRs are just "less experimental" than the public release version.

Some of these bugs have been open for a long time, like 5 years. And there has been little or no work done on them. I don't blame any individual contributor to Firefox; it is really the responsibility of the overarching organization, Mozilla, to manage product development, deploy resources, and generate revenue to pay for development. I don't think Mozilla is investing enough resources, whether they be volunteers or paid staff, consultants, or contractors, to make Firefox a product that is or ever will be ready for release if the status quo is maintained.

If setting status flags on bugs is useless, why do you even have a status flagging system?

Why do you even track bugs if you are never going to work on them?

In some ways, you could say that the entire bugzilla infrastructure is a waste of everyone's time because no matter how many or how severe the bugs are, you don't have any resources to address the problems anyway?

Maybe Mozilla should just end the development of Firefox entirely?

Comment 11

[Emilio Cobos Álvarez (:emilio)]

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.

Comment 12

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

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.

Comment 13

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

Closing because no crashes reported for 12 weeks.