Closed Bug 1364798 Opened 7 years ago Closed 7 years ago

Crash in shutdownhang | ZwWaitForKeyedEvent | RtlSleepConditionVariableCS | SleepConditionVariableCS in GC

Categories

(Core :: JavaScript: GC, defect)

All
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 833143
Tracking Status
firefox-esr52 --- wontfix
firefox55 --- wontfix
firefox56 + fixed
firefox57 + unaffected

People

(Reporter: MatsPalmgren_bugz, Unassigned)

References

Details

(Keywords: crash, topcrash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-1a796172-3898-4f5b-a699-4da0c0170514.
=============================================================

We have a fairly high volume of crashes with this signature: 479 in the past 7 days.
It's currently #19 on the v54b Top Crash list.
This signature is Windows specific, but I suspect it might occur under a different
signature on other platforms.  All crashes have:
MOZ_CRASH Reason:  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
so it might be a deadlock in JS GC during shutdown?

https://hg.mozilla.org/releases/mozilla-release/annotate/d345b657d381/toolkit/xre/nsXREDirProvider.cpp#l1254

KiFastSystemCallRet
ZwWaitForKeyedEvent
RtlSleepConditionVariableCS
SleepConditionVariableCS
js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&)
js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>)
js::gc::GCRuntime::joinTask(js::GCParallelTask&, js::gcstats::Phase, js::AutoLockHelperThreadState&)
js::gc::GCRuntime::beginSweepingZoneGroup(js::AutoLockForExclusiveAccess&)
js::gc::GCRuntime::beginSweepPhase(bool, js::AutoLockForExclusiveAccess&)
js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason, js::AutoLockForExclusiveAccess&)
js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason)
js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason)
js::gc::GCRuntime::gc(JSGCInvocationKind, JS::gcreason::Reason)
JS_GC(JSContext*)
nsXREDirProvider::DoShutdown()
ScopedXPCOMStartup::~ScopedXPCOMStartup()
mozilla::UniquePtr<ScopedXPCOMStartup, mozilla::DefaultDelete<ScopedXPCOMStartup> >::reset(ScopedXPCOMStartup*)
XREMain::XRE_main(int, char** const, mozilla::BootstrapConfig const&)
XRE_main(int, char** const, mozilla::BootstrapConfig const&)
...
This crash signature is currently Top Crasher #1 for FF 56.0b

https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=56.0b

1 	11.02% 	-0.52% 	
shutdownhang | ZwWaitForKeyedEvent | RtlSleepConditionVariableCS | SleepConditionVariableCS
Count   15978
Win	15978
Mac	0
Lin	0
Installs 12223
Is GC? 0
2016-03-08
1389021 (RESOLVED FIXED)
1364798 (NEW, UNASSIGNED)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Actually, based on the signature posted in the base level comment, I'm going to undupe. The dupe was a gfx related issue, this appears to be in gc. My mistake.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Blocks: 1402037
Guys, can you help with that?
The volume is huge and this is only on beta... We release 56 next Thursday, I am afraid that it might become a driver for a 56 dot release.

Even if this is a "shutdown hang crash", I am concerned that it might hide something.
Flags: needinfo?(nihsanullah)
Flags: needinfo?(jcoppeard)
Keywords: topcrash
This is similar to bug 1401481, which also involves the main thread waiting for JS helper threads during shutdown.
See Also: → 1401481
Oh, sorry, I should have looked at the actual crashes on beta. The beta crashes I see are different than the one in this bug.

83% of the crashes I see on b12 look like this: bp-9e395957-e1a7-4491-8a07-6877a0170922

That looks like bug 1389021. You should find a graphics person to look into those, and probably file a new bug, or post in bug 1389021.

I actually removed the shutdown GC we see in comment 0 over in bug 833143 (in 56), so I'll close this.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Flags: needinfo?(sledru)
Flags: needinfo?(nihsanullah)
Flags: needinfo?(jcoppeard)
Resolution: --- → DUPLICATE
Summary: Crash in shutdownhang | ZwWaitForKeyedEvent | RtlSleepConditionVariableCS | SleepConditionVariableCS → Crash in shutdownhang | ZwWaitForKeyedEvent | RtlSleepConditionVariableCS | SleepConditionVariableCS in GC
Andrew, this is quite confusing to me with these 3 bugs, touching different part of the codes.
Anyway, the critical bug seems to be bug 1389021 and it seems that we have a patch which landed.
(In reply to Sylvestre Ledru [:sylvestre] from comment #7)
> Andrew, this is quite confusing to me with these 3 bugs, touching different
> part of the codes.
> Anyway, the critical bug seems to be bug 1389021 and it seems that we have a
> patch which landed.

Yeah, this signature is terrible. Somebody should probably figure out what we could add to the prefix and skip lists so they are split up more.
(In reply to Andrew McCreight [:mccr8] from comment #8)
Thanks Andrew.  I've filed bug 1402323 for the GC-related shutdown hangs I could find.
Previous comment had the wrong bug #, skip list work is in bug 1402037.
Flags: needinfo?(sledru)
No longer blocks: 1402037
Depends on: 1402037
You need to log in before you can comment on or make changes to this bug.