1622110 - Lots of shutdown hangs with URL chrome://gfxsanity/content/sanitytest.html

Status: NEW

(Core :: Graphics, task, P3)

Description

[Andrew McCreight [:mccr8]]

While looking through the shutdown hangs, I've noticed an oddly large number of them have the URL chrome://gfxsanity/content/sanitytest.html , which I think is some kind of self testing the graphics code does. Looking at 76 only, we have about 7600 shutdownkill hang reports, and around 1000 crash reports with the sanity test URL. In fact, it looks like almost all of the crash reports with sanitytest URLs (all but 6!) are hangs. Maybe there's nothing to be done, but maybe that's something worth investigating.

Here's a couple of examples:
bp-998a7de5-fc1a-4d22-8025-5e0530200312
bp-742d9ad8-a000-4166-84e3-db71f0200312

Comment 1

[Andrew McCreight [:mccr8]]

Maybe sanitytest.html is loaded in a content process that opens and shuts down quickly? That might cause issues. The hangs are in all sorts of different code, so it doesn't feel like the test itself would be the problem.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Has this been happening for a while is it a more recent thing?

Comment 3

[Andrew McCreight [:mccr8]]

Most of the crashes are on 75 and later, but maybe we just autosubmit content process crashes on beta. I'm not sure of this history of this. We've mostly been ignoring shutdown hangs until recently.

Comment 4

[Jens Stutte [:jstutte]]

This is still happening

I cracked up one of those:

 	ntdll.dll!NtWaitForAlertByThreadId()	Unbekannt
 	ntdll.dll!RtlSleepConditionVariableSRW()	Unbekannt
 	KERNELBASE.dll!SleepConditionVariableSRW()	Unbekannt
 	mozglue.dll!mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl & lock) Zeile 50	C++
 	[Inlineframe] xul.dll!mozilla::OffTheBooksCondVar::Wait() Zeile 58	C++
 	[Inlineframe] xul.dll!mozilla::TaskController::GetRunnableForMTTask(bool aReallyWait) Zeile 586	C++
 	xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Zeile 1139	C++
 	[Inlineframe] xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Zeile 465	C++
 	[Inlineframe] xul.dll!mozilla::SpinEventLoopUntil(const nsTSubstring<char> & aVeryGoodReasonToDoThis, mozilla::ThreadEventTarget::Dispatch::<lambda_4> && aPredicate, nsIThread * aThread) Zeile 176	C++
>	[Inlineframe] xul.dll!mozilla::ThreadEventTarget::Dispatch(already_AddRefed<nsIRunnable> aEvent, unsigned int aFlags) Zeile 89	C++
 	xul.dll!nsThread::Dispatch(already_AddRefed<nsIRunnable> aEvent, unsigned int aFlags) Zeile 676	C++
 	xul.dll!mozilla::ChildProfilerController::ShutdownAndMaybeGrabShutdownProfileFirst(nsTString<char> * aOutShutdownProfile) Zeile 107	C++
 	xul.dll!mozilla::ChildProfilerController::GrabShutdownProfileAndShutdown() Zeile 60	C++
 	xul.dll!mozilla::dom::ContentChild::ShutdownInternal() Zeile 3026	C++
 	xul.dll!mozilla::dom::ContentChild::RecvShutdown() Zeile 2968	C++
 	xul.dll!mozilla::dom::PContentChild::OnMessageReceived(const IPC::Message & msg__) Zeile 12123	C++

It seems something goes wrong with the DISPATCH_SYNC and we are stuck inside its SpinEventLoopUntil. AFAICS from that crash, the ProfilerChild thread is just waiting for new events:

>	mozglue.dll!mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl & lock) Zeile 50	C++
 	[Inlineframe] xul.dll!mozilla::OffTheBooksCondVar::Wait() Zeile 58	C++
 	[Inlineframe] xul.dll!mozilla::ThreadEventQueue::GetEvent(bool aMayWait, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> * aLastEventDelay) Zeile 179	C++
 	xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Zeile 1141	C++
 	[Inlineframe] xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Zeile 465	C++
 	xul.dll!mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate * aDelegate) Zeile 330	C++
 	[Inlineframe] xul.dll!MessageLoop::RunInternal() Zeile 381	C++
 	xul.dll!MessageLoop::RunHandler() Zeile 375	C++
 	xul.dll!MessageLoop::Run() Zeile 357	C++

That would imply, that nsThreadSyncDispatch::Run ran on the target thread, unless there is a way for bool success = mSink->PutEvent(...) to fail without returning false.

Comment 5

[Jens Stutte [:jstutte]]

There might be an edge case around mIsShutDown here while dispatching back to the mOrigin, though it is not clear to me how that could have been triggered.