1480181 - Crash in bool CCGraphBuilder::BuildGraph

Status: RESOLVED DUPLICATE of bug 1272230

(Core :: XPCOM, defect, P2)

Description

[Marcia Knous [:marcia]]

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

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

Comment 1

[Marion Daly [:mdaly]]

:asuth, can you confirm if the bug can be tranced to build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=547144f5596c1a146b208d68d93950a6313080ca&tochange=5a8107262015714d2907a85abc24c847ad9b32d2

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 3

[Marcia Knous [:marcia]]

Marking this as sec sensitive since there is at least one possible UAF crash address that shows up: https://crash-stats.mozilla.com/report/index/ff87f512-ec32-4af7-80c9-3c9320180809. 

Here are some of the crashing URLs:
*https://www.youtube.com/watch?v=ypNm7g33RHw 
*https://www.yandex.ru/ 
*https://www.w3schools.com/tags/att_td_align.asp 
*https://forums.watchuseek.com/f2/retailers-should-i-visit-toronto-2371458.html

Comment 4

[Marion Daly [:mdaly]]

(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?

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

(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.

Comment 6

[Andrew McCreight [:mccr8]]

This is just some kind of signature change (the extra "bool").

Comment 7

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

The crash rate is still high on release 62 with the signatures in bug 1272230, but from discussion there, it doesn't seem actionable.