1453897 - Crash in nsCOMPtr<T>::nsCOMPtr<T> | nsRuleNode::nsRuleNode

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-71071944-7dc5-43b0-80bc-a36550180412.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll nsCOMPtr<nsILoadContextInfo>::nsCOMPtr<nsILoadContextInfo> mfbt/RefPtr.h:112
1 xul.dll nsRuleNode::nsRuleNode layout/style/nsRuleNode.cpp:1730
2 xul.dll nsRuleNode::Transition layout/style/nsRuleNode.cpp:1814
3 xul.dll nsRuleWalker::DoForward layout/style/nsRuleWalker.h:32
4 xul.dll nsRuleWalker::Forward layout/style/nsRuleWalker.h:43
5 xul.dll nsHTMLCSSStyleSheet::ElementRulesMatching layout/style/nsHTMLCSSStyleSheet.cpp:79
6 xul.dll nsHTMLCSSStyleSheet::RulesMatching layout/style/nsHTMLCSSStyleSheet.cpp:66
7 xul.dll EnumRulesMatching<ElementRuleProcessorData> layout/style/nsStyleSet.cpp:780
8 xul.dll nsStyleSet::FileRules layout/style/nsStyleSet.cpp:1158
9 xul.dll nsStyleSet::ResolveStyleForInternal layout/style/nsStyleSet.cpp:1338

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

crashes with this signature are regressing in firefox 60 - frequently a uaf.

there were a number of reports early in the 61.0a1 nightly cycle as well, but the last report we got from 61 was build 20180317220121, so something seems to have fixed or moved the signature.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

There's no way this code crashes in FF60 since it's gone. In any case all that code is gone from trunk, so should we mark this WONTFIX?

Comment 2

[Daniel Holbert [:dholbert]]

WONTFIX = there issue is valid, but we're intentionally declining to take any patches to fix it. (e.g. because the cost/benefit isn't a good tradeoff, or something like that)  WONTFIX is & should be used very rarely.

In this case I think the correct resolution would be either WORKSFORME (in the sense that "the issue has gone away in latest builds"), or more directly, FIXED with a dependency on whatever bug removed the code.

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #1)
> There's no way this code crashes in FF60 since it's gone.

The crash report in comment 0 shows that it's in a build labeled "60.:0b11" -- are you sure this code is gone in Firefox 60?

(Also, RE wontfix and such: I was talking about the bug resolution status, but it's a slightly different call for status flags, e.g. status-
firefox60:[wontfix|unaffected|fixed] etc.)

Comment 4

[Emilio Cobos Álvarez (:emilio)]

https://bugzilla.mozilla.org/show_bug.cgi?id=stylo-chrome was fixed in 60, so there should be nobody using the old style system in 60, unless they turned it on intentionally.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Daniel, let me know if you're fine with resolving this as FIXED depending on stylo-chrome, otherwise we can reopen / resolve as you think it's better :)

Comment 6

[Daniel Holbert [:dholbert]]

Gotcha - that makes sense.  So this user must've flipped a pref, I suppose?

(Seems like it'll be worth monitoring crash volume here in case there's reason to believe a lot of users have this configuration.  But aside from that: FIXED-by-stylo-chrome seems reasonable. Thanks!)

Comment 7

[Julien Cristau [:jcristau] (back April 22)]

updating status flags per emilio's comments