Closed
Bug 1364798
Opened 7 years ago
Closed 7 years ago
Crash in shutdownhang | ZwWaitForKeyedEvent | RtlSleepConditionVariableCS | SleepConditionVariableCS in GC
Categories
(Core :: JavaScript: GC, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 833143
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&) ...
Comment 1•7 years ago
|
||
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)
Updated•7 years ago
|
status-firefox55:
--- → unaffected
status-firefox56:
--- → affected
status-firefox57:
--- → affected
status-firefox-esr52:
--- → affected
tracking-firefox56:
--- → ?
tracking-firefox57:
--- → ?
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Comment 3•7 years ago
|
||
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 → ---
Comment 4•7 years ago
|
||
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.
Comment 5•7 years ago
|
||
This is similar to bug 1401481, which also involves the main thread waiting for JS helper threads during shutdown.
See Also: → 1401481
Comment 6•7 years ago
|
||
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 ago → 7 years ago
Flags: needinfo?(sledru)
Flags: needinfo?(nihsanullah)
Flags: needinfo?(jcoppeard)
Resolution: --- → DUPLICATE
Updated•7 years ago
|
Updated•7 years ago
|
Summary: Crash in shutdownhang | ZwWaitForKeyedEvent | RtlSleepConditionVariableCS | SleepConditionVariableCS → Crash in shutdownhang | ZwWaitForKeyedEvent | RtlSleepConditionVariableCS | SleepConditionVariableCS in GC
Comment 7•7 years ago
|
||
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.
Comment 8•7 years ago
|
||
(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.
Comment 9•7 years ago
|
||
(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.
Comment hidden (offtopic) |
Comment 11•7 years ago
|
||
Previous comment had the wrong bug #, skip list work is in bug 1402037.
Updated•7 years ago
|
Flags: needinfo?(sledru)
Updated•7 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•