Closed Bug 1275167 Opened 5 years ago Closed 3 years ago

Crash in shutdownhang | WaitForSingleObject | WaitForSingleObjectEx | PR_WaitCondVar | CondVar::Wait | nsEventQueue::GetEvent | nsThread::ProcessNextEvent | XPTC__InvokebyIndex or nsThread::Shutdown

Categories

(Core :: XPCOM, defect)

Unspecified
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox49 --- affected

People

(Reporter: ting, Unassigned)

References

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-68cd8c5f-936e-436e-a401-a6deb2160523.
=============================================================

There are 27 crashes at #1 [shutdownhang | ntdll.dll@0xa5164] of Nightly 20160522030240, this is one of them.
There're two different stacks:

https://crash-stats.mozilla.com/report/index/a6a989f7-640d-4df1-9bf7-893bd2160523
https://crash-stats.mozilla.com/report/index/68cd8c5f-936e-436e-a401-a6deb2160523
  3 	xul.dll 	nsAppShell::ProcessNextNativeEvent(bool)
  4 	xul.dll 	mozilla::CondVar::Wait(unsigned int)
  5 	xul.dll 	nsEventQueue::GetEvent(bool, nsIRunnable**, mozilla::BaseAutoLock<mozilla::Mutex>&)
  6 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*)
  7 	xul.dll 	XPTC__InvokebyIndex
  8 		@0xb61a1c1400 	
  9 	xul.dll 	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)

https://crash-stats.mozilla.com/report/index/b1808dc8-7415-4700-b29c-924cf2160523
https://crash-stats.mozilla.com/report/index/09b9ffd6-5db9-4692-9fc9-9ded72160523
  3 	xul.dll 	nsAppShell::ProcessNextNativeEvent(bool)
  4 	xul.dll 	mozilla::CondVar::Wait(unsigned int)
  5 	xul.dll 	nsEventQueue::GetEvent(bool, nsIRunnable**, mozilla::BaseAutoLock<mozilla::Mutex>&)
  6 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*)
  7 	xul.dll 	nsThread::Shutdown()
  8 	xul.dll 	nsThreadManager::Shutdown()
  9 	xul.dll 	mozilla::ShutdownXPCOM(nsIServiceManager*)
Flags: needinfo?(dd.mozilla)
Flags: needinfo?(dd.mozilla)
Likely fallout from event queue unification.
Flags: needinfo?(khuey)
Why do you believe that?  These look like the shutdown hangs we've had forever.
Flags: needinfo?(khuey) → needinfo?(benjamin)
I thought this was filed as a regression on nightly. Ting-Yu, if this is just missing symbols for ntdll.dll, please ping Ted to get the Windows symbols fixed and mark this a duplicate of the normal shutdownhang bugs.
Flags: needinfo?(benjamin) → needinfo?(janus926)
I'm 99% sure it's just missing symbols for ntdll, and because shutdown hangs are essentially guaranteed to be us waiting on condvars ...
I filed bug 1270190 on the missing symbol issue.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1270190
There are a fair number of deadlocks which aren't just "waiting for a message to arrive", and occasional iloops or blocked on I/O.

We really need to be better, for the shutdown hangs which are in fact waiting for a message to arrive, at identifying which message we're waiting for.
It would be nice if for the ones where we came through XPTC__InvokebyIndex we could get the JS stack ... those are basically impossible to track down without it.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> I thought this was filed as a regression on nightly. Ting-Yu, if this is
> just missing symbols for ntdll.dll, please ping Ted to get the Windows
> symbols fixed and mark this a duplicate of the normal shutdownhang bugs.

No, this is not. There're many shutdown hang crashes with missing symbols from ntdll.dll and kernelbase.dll, but I filed bugs based on where it gets stucked, here it is https://dxr.mozilla.org/mozilla-central/rev/829d3be6ba648b838ee1953fdfa1a477dace752f/xpcom/threads/nsEventQueue.cpp#55.
Flags: needinfo?(janus926)
There are already bugs for most shutdown hangs. When there are good symbols, these hangs are grouped correctly by the *caller* of ProcessNextEvent. For instance bug 1272862, bug 1267692, bug 1230515.

So as filed this bug is mostly-useless. If you want to make this about one specific kind of shutdownhang, let's do that (and make sure that the signature reflects the choice). Otherwise the bug is too generic to track or fix.
Flags: needinfo?(janus926)
(In reply to Ting-Yu Chou [:ting] from comment #0)
> This bug was filed from the Socorro interface and is 
> report bp-68cd8c5f-936e-436e-a401-a6deb2160523.
> =============================================================
> 
> There are 27 crashes at #1 [shutdownhang | ntdll.dll@0xa5164] of Nightly
> 20160522030240, this is one of them.

IMO, an addon (or us!) is calling on processNextEvent(mayWait = true) and blocks the main thread.  Bad is we cannot unwind Ion generated stacks in crash reports (I know it's possible, tho).  And another bad is that we don't include JS stack somehow (DumpJSStack() output).  I think when this is just a hang (not an actual crash) it's possible to collect it.

Personally, I think having symbols for ntdll won't help here much.  hence I'm curious why this has been marked as dup of bug 1270190.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Crash Signature: [@ shutdownhang | ntdll.dll@0xa5164] → [@ shutdownhang | ntdll.dll@0xa5164] [@ shutdownhang | WaitForSingleObject | WaitForSingleObjectEx | PR_WaitCondVar | CondVar::Wait | nsEventQueue::GetEvent | nsThread::ProcessNextEvent | XPTC__InvokebyIndex] [@ shutdownhang | WaitForSingleObject | Wait…
Flags: needinfo?(janus926)
Summary: Crash in shutdownhang | nsEventQueue::GetEvent | nsThread::ProcessNextEvent → Crash in shutdownhang | WaitForSingleObject | WaitForSingleObjectEx | PR_WaitCondVar | CondVar::Wait | nsEventQueue::GetEvent | nsThread::ProcessNextEvent | XPTC__InvokebyIndex or nsThread::Shutdown
Closing because no crash reported since 12 weeks.
Status: REOPENED → RESOLVED
Closed: 5 years ago3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.