Closed Bug 1480181 Opened Last year Closed Last year

Crash in bool CCGraphBuilder::BuildGraph

Categories

(Core :: XPCOM, defect, P2, critical)

Unspecified
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1272230
Tracking Status
firefox62 --- unaffected
firefox63 --- wontfix

People

(Reporter: marcia, Unassigned)

Details

(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is
report bp-69691573-ce2a-49a4-a441-0e8d20180719.
=============================================================

Seen while looking at nightly crash stats - fairly small volume crash which started on Windows using 20180718100918: https://bit.ly/2Mawq7U. 17 crashes/13 installations.

Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=547144f5596c1a146b208d68d93950a6313080ca&tochange=5a8107262015714d2907a85abc24c847ad9b32d2

Top 10 frames of crashing thread:

0 xul.dll bool CCGraphBuilder::BuildGraph xpcom/base/nsCycleCollector.cpp:2358
1 xul.dll void nsCycleCollector::MarkRoots xpcom/base/nsCycleCollector.cpp:2964
2 xul.dll nsCycleCollector::Collect xpcom/base/nsCycleCollector.cpp:3759
3 xul.dll nsCycleCollector_collect xpcom/base/nsCycleCollector.cpp:4328
4 xul.dll static void mozilla::CycleCollectedJSRuntime::GCCallback xpcom/base/CycleCollectedJSRuntime.cpp:851
5 xul.dll js::gc::GCRuntime::maybeCallGCCallback js/src/gc/GC.cpp:7430
6 xul.dll js::gc::GCRuntime::gcCycle js/src/gc/GC.cpp:7518
7 xul.dll js::gc::GCRuntime::collect js/src/gc/GC.cpp:7680
8 xul.dll JS::NonIncrementalGC js/src/gc/GC.cpp:8604
9 xul.dll ?WorkerRun@GarbageCollectRunnable@?A@dom@mozilla@@EEAA_NPEAUJSContext@@PEAVWorkerPrivate@23@@Z$6b14f484ac237380d5d109786ce4a31e dom/workers/WorkerPrivate.cpp:894

=============================================================
Priority: -- → P2
I'm not sure the crash reports are consistent enough to infer much at this point.  Many of the crashes are on the main thread (not workers), and in some of those cases, there aren't even any active worker threads.  Also, the crashes involving workers don't seem to be consistent: some are hybrid-target wrapped control runnables, some are normal runnables, some are normal GC/cycle-collect runnables.

Moreover, the crash addresses don't seem to be consistent, but there also aren't a lot of crashes.  Since the cycle collector traverses a lot of memory, I'd suspect that these crashes are more an indication of the cycle collector being the victim of traversing memory that's been corrupted by other logic.  I'd suggest looking for upticks in other signatures that are indicative of memory corruption, possibly with a higher crash rate.
Flags: needinfo?(bugmail)
(In reply to Andrew Sutherland [:asuth] from comment #2)
> I'm not sure the crash reports are consistent enough to infer much at this
> point.  Many of the crashes are on the main thread (not workers), and in
> some of those cases, there aren't even any active worker threads.  Also, the
> crashes involving workers don't seem to be consistent: some are
> hybrid-target wrapped control runnables, some are normal runnables, some are
> normal GC/cycle-collect runnables.
> 
> Moreover, the crash addresses don't seem to be consistent, but there also
> aren't a lot of crashes.  Since the cycle collector traverses a lot of
> memory, I'd suspect that these crashes are more an indication of the cycle
> collector being the victim of traversing memory that's been corrupted by
> other logic.  I'd suggest looking for upticks in other signatures that are
> indicative of memory corruption, possibly with a higher crash rate.

Should probably conduct a followup on this, perhaps a good research bug for perry or yaron?
(In reply to Marion Daly [:mdaly] from comment #4)
> Should probably conduct a followup on this, perhaps a good research bug for
> perry or yaron?

The last crash report was for August 24th and that was for the main thread again.  I'm not sure there's much point in anyone investigating at this point, but I'll move this to the cycle collector's component and needinfo over to :mccr8, the cycle collector module owner.
Component: DOM: Workers → XPCOM
Flags: needinfo?(continuation)
This is just some kind of signature change (the extra "bool").
Group: dom-core-security
Status: NEW → RESOLVED
Closed: Last year
Flags: needinfo?(continuation)
Resolution: --- → DUPLICATE
Duplicate of bug: 1272230
The crash rate is still high on release 62 with the signatures in bug 1272230, but from discussion there, it doesn't seem actionable.
You need to log in before you can comment on or make changes to this bug.