Crash in PLDHashTable::Add | CCGraphBuilder::NoteJSChild

NEW
Unassigned

Status

()

P3
critical
2 years ago
7 days ago

People

(Reporter: davidb, Unassigned)

Tracking

({crash, nightly-community, regression})

unspecified
x86
Windows XP
crash, nightly-community, regression
Points:
---

Firefox Tracking Flags

(firefox49 wontfix, firefox50 wontfix, firefox51 wontfix, firefox52 wontfix, firefox-esr52 wontfix, firefox53 wontfix, firefox56 wontfix, firefox57 wontfix, firefox58 wontfix, firefox59 wontfix, firefox60 wontfix, firefox61 wontfix, firefox62 fix-optional, firefox63 fix-optional)

Details

(crash signature)

Possibly a regression.
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
Crash volume for signature 'PLDHashTable::Add | CCGraphBuilder::NoteJSChild':
 - nightly (version 52): 2 crashes from 2016-09-19.
 - aurora  (version 51): 10 crashes from 2016-09-19.
 - beta    (version 50): 253 crashes from 2016-09-20.
 - release (version 49): 1257 crashes from 2016-09-05.
 - esr     (version 45): 0 crashes from 2016-06-01.

Crash volume on the last weeks (Week N is from 10-03 to 10-09):
            W. N-1  W. N-2
 - nightly       1       1
 - aurora       10       0
 - beta        232      21
 - release    1049     207
 - esr           0       0

Affected platform: Windows

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly           #481
 - aurora  #300      #152
 - beta    #62       #111
 - release #53       #64
 - esr
status-firefox52: --- → affected

Updated

2 years ago
Keywords: regression
Any thoughts on this, mccr8?
status-firefox49: affected → wontfix
Flags: needinfo?(continuation)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #3)
> Any thoughts on this, mccr8?

I looked at this before, and I wasn't able to come up with anything. It is probably an OOM crash, given that almost all of the crashes are null derefs, and the "system memory use" numbers are very high. Maybe we're not null checking some allocation somewhere.
Flags: needinfo?(continuation)
Seems unactionable given comment 4.
Priority: -- → P3

Comment 6

2 years ago
https://crash-stats.mozilla.com/report/index/18c65c27-fae3-4fa3-a7c9-7db442161204
If that's helping somehow, firefox was idle when it crashed.

Comment 7

2 years ago
Too late to fix in 50.1.0 release
status-firefox50: affected → wontfix
status-firefox53: --- → affected

Comment 8

2 years ago
njn, can the uptime team in Taipei take a look at this?
Flags: needinfo?(n.nethercote)
(In reply to Jim Mathies [:jimm] from comment #8)
> njn, can the uptime team in Taipei take a look at this?

Kan-Ru would be a better person to ask about that...
Flags: needinfo?(n.nethercote) → needinfo?(kchen)
I tried to look at this but like comment 4 said, it's likely a missing OOM check somewhere else. Maybe we can add a MOZ_DIAGNOSTIC_ASSERT to find out which pointer that got added to CC is nullptr. Or we can try to look at Coverity and see if we can find where we miss a check.

That said, given the affected user were already OOMing, I doubt that fixing this can really help them.
status-firefox51: affected → wontfix
status-firefox52: affected → fix-optional
status-firefox53: affected → fix-optional
Flags: needinfo?(kchen)
Duplicate of this bug: 1342556
Crash Signature: [@ PLDHashTable::Add | CCGraphBuilder::NoteJSChild] → [@ PLDHashTable::Add | CCGraphBuilder::NoteJSChild] [@ PLDHashTable::Add | TraversalTracer::onChild] [@ PLDHashTable::Add | js::DispatchTyped<T>] [@ PtrToNodeMatchEntry ]
Duplicate of this bug: 1396374
This is a top crash in 55.0.3 and in beta 56. If most of these are win 7 and OOM crashes, maybe this is not actionable. 

There are also significant Fennec crashes.
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox56: affected → fix-optional
status-firefox57: affected → fix-optional

Updated

10 months ago
Duplicate of this bug: 1406733

Comment 15

6 months ago
Signature report for PLDHashTable::Add | TraversalTracer::onChild

Showing results from 7 days ago

Firefox 	60.0a1 	12 	1.0% 	16
Firefox 	59.0b6 	7 	0.6% 	6
Firefox 	59.0b5 	33 	2.8% 	24
Firefox 	59.0b4 	26 	2.2% 	34
Firefox 	59.0b3 	8 	0.7% 	6
Firefox 	58.0b99 	4 	0.3% 	5
Firefox 	58.0b16 	3 	0.3% 	3
Firefox 	58.0b14 	3 	0.3% 	3
Firefox 	58.0 	79 	6.8% 	67
Firefox 	57.0b4 	1 	0.1% 	1
Firefox 	57.0.4 	36 	3.1% 	35
Firefox 	57.0.2 	1 	0.1% 	1
status-firefox58: --- → affected
status-firefox59: --- → affected
status-firefox60: --- → affected
Keywords: nightly-community
status-firefox52: fix-optional → wontfix
status-firefox53: fix-optional → wontfix
status-firefox56: fix-optional → wontfix
status-firefox57: fix-optional → wontfix
status-firefox58: affected → wontfix
status-firefox59: affected → wontfix
status-firefox60: affected → fix-optional
status-firefox-esr52: --- → wontfix
Duplicate of this bug: 1477751
One place where we can end up with an incomplete hash entry is in |CCGraphBuilder::AddNode| [1]. If |mNodeBuilder.Add| fails you end up with an incomplete |mGraph| entry which would lead to null deref in comparison.

A simple solution is to remove the entry if |mNodeBuilder.Add| fails, but it's not clear what downstream affects that will have as most consumers don't really check for failure.

[1] https://searchfox.org/mozilla-central/rev/ad36eff63e208b37bc9441b91b7cea7291d82890/xpcom/base/nsCycleCollector.cpp#2278-2286
status-firefox60: fix-optional → wontfix
status-firefox61: --- → affected
status-firefox62: --- → affected
status-firefox63: --- → affected
status-firefox61: affected → wontfix
status-firefox62: affected → fix-optional
status-firefox63: affected → fix-optional
You need to log in before you can comment on or make changes to this bug.