This bug was filed from the Socorro interface and is report bp-8dba91b9-8203-475a-9405-bcf2a2160819. ============================================================= More here: https://crash-stats.mozilla.com/signature/?product=Firefox&signature=PLDHashTable%3A%3AAdd%20%7C%20CCGraphBuilder%3A%3ANoteJSChild&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_sort=-date&page=1#reports
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
Any thoughts on this, mccr8?
status-firefox49: affected → wontfix
(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.
Seems unactionable given comment 4.
Priority: -- → P3
https://crash-stats.mozilla.com/report/index/18c65c27-fae3-4fa3-a7c9-7db442161204 If that's helping somehow, firefox was idle when it crashed.
Too late to fix in 50.1.0 release
status-firefox50: affected → wontfix
njn, can the uptime team in Taipei take a look at this?
(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
Crash Signature: [@ PLDHashTable::Add | CCGraphBuilder::NoteJSChild] → [@ PLDHashTable::Add | CCGraphBuilder::NoteJSChild] [@ PLDHashTable::Add | TraversalTracer::onChild] [@ PLDHashTable::Add | js::DispatchTyped<T>] [@ PtrToNodeMatchEntry ]
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
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
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
One place where we can end up with an incomplete hash entry is in |CCGraphBuilder::AddNode| . 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.  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.