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

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Ting-Yu Chou [:ting] (away)]

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.

Comment 1

[Ting-Yu Chou [:ting] (away)]

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*)

Comment 2

[Benjamin Smedberg]

Likely fallout from event queue unification.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Why do you believe that?  These look like the shutdown hangs we've had forever.

Comment 4

[Benjamin Smedberg]

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.

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I'm 99% sure it's just missing symbols for ntdll, and because shutdown hangs are essentially guaranteed to be us waiting on condvars ...

Comment 6

[Andrew McCreight [:mccr8]]

I filed bug 1270190 on the missing symbol issue.

Comment 7

[Benjamin Smedberg]

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.

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 9

[Ting-Yu Chou [:ting] (away)]

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

Comment 10

[Benjamin Smedberg]

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.

Comment 11

[Honza Bambas (:mayhemer)]

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

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.