1143873 - crash in shutdownhang | mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*)

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[u279076]

This bug was filed from the Socorro interface and is 
report bp-d9088171-85f4-4450-8ce1-caed32150309.
=============================================================
0 	xul.dll 	mozilla::`anonymous namespace'::RunWatchdog(void*) 	toolkit/components/terminator/nsTerminator.cpp
1 	nss3.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c
2 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c
3 	msvcr120.dll 	_callthreadstartex 	f:\dd\vctools\crt\crtw32\startup\threadex.c:376
4 	msvcr120.dll 	msvcr120.dll@0x2c000 	
5 	kernel32.dll 	BaseThreadInitThunk 	
6 	ntdll.dll 	__RtlUserThreadStart 	
7 	ntdll.dll 	_RtlUserThreadStart 	
=============================================================
More reports:https://crash-stats.mozilla.com/report/list?product=Firefox&signature=shutdownhang+|+mozilla%3A%3AEventDispatcher%3A%3ADispatch%28nsISupports*%2C+nsPresContext*%2C+mozilla%3A%3AWidgetEvent*%2C+nsIDOMEvent*%2C+nsEventStatus*%2C+mozilla%3A%3AEventDispatchingCallback*%2C+nsCOMArray%3Cmozilla%3A%3Adom%3A%3AEventTarget%3E*%29

Volume: ~1200 reports in the last week (not a topcrash)
Platform: ~65% are on Windows 7, ~30% are on other Windows, and 5% are on Mac OS X
Product: All reports are on Firefox 36 with 95% on 36.0.1
URLs: facebook, google, twitter, yahoo, and youtube are all common
Comments: several people mention this happening when the close Firefox

Florin, can you please see if your team can shake out steps to reproduce for this?

Comment 1

[u279076]

[Tracking Requested - why for this release]: This is not a topcrash but volume is still significant and reports seem to indicate this is a Firefox 36 regression.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Do we have any reports with sane stack trace?

Comment 3

[u279076]

(In reply to Olli Pettay [:smaug] from comment #2)
> Do we have any reports with sane stack trace?

I'm not sure what you mean by that. If you click the 'more reports' link above you can go through the reports to see if there's something you're looking for.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Yes, but I couldn't see any normal stacks.
Looking again...

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

None of the stack traces I looked at have EventDispatcher::Dispatch

Comment 6

[u279076]

(In reply to Olli Pettay [:smaug] from comment #5)
> None of the stack traces I looked at have EventDispatcher::Dispatch

So without that information there's nothing we can do?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Right.

Perhaps ted knows why the stack looks like what it does.

Comment 8

[(not currently active) Ted Mielczarek]

(In reply to Olli Pettay [:smaug] from comment #5)
> None of the stack traces I looked at have EventDispatcher::Dispatch

Apparently shutdownhang crashes get their signatures generated in a different way. If you click "Show other threads" beneath the crashing thread stack you'll see in Thread 0 (the main Gecko thread):
Thread 0
Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*) 	dom/events/EventDispatcher.cpp 

I guess since in a chromehang we're MOZ_CRASHing in a background thread (the watchdog thread) we assign blame to the top frame of Thread 0.

Comment 9

[u279076]

Thanks for pointing that out, Ted.

Here is the stack for Thread 0:
0 	xul.dll 	mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*) 	dom/events/EventDispatcher.cpp
1 	xul.dll 	mozilla::EventDispatcher::DispatchDOMEvent(nsISupports*, mozilla::WidgetEvent*, nsIDOMEvent*, nsPresContext*, nsEventStatus*) 	dom/events/EventDispatcher.cpp
2 	xul.dll 	nsINode::DispatchEvent(nsIDOMEvent*, bool*) 	dom/base/nsINode.cpp
3 	xul.dll 	mozilla::dom::EventTargetBinding::dispatchEvent 	obj-firefox/dom/bindings/EventTargetBinding.cpp
4 	xul.dll 	mozilla::dom::EventTargetBinding::genericMethod 	obj-firefox/dom/bindings/EventTargetBinding.cpp
5 		@0x4e422f 	
6 		@0xffffff87 	
7 	xul.dll 	EnterIon 	js/src/jit/Ion.cpp
8 	xul.dll 	js::jit::IonCannon(JSContext*, js::RunState&) 	js/src/jit/Ion.cpp
9 	xul.dll 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp
10 	xul.dll 	js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp
11 	xul.dll 	js::CallOrConstructBoundFunction(JSContext*, unsigned int, JS::Value*) 	js/src/jsfun.cpp
12 	xul.dll 	js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp
13 	xul.dll 	js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) 	js/src/vm/Interpreter.cpp
14 	xul.dll 	mozilla::dom::EventListener::HandleEvent(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, mozilla::ErrorResult&) 	obj-firefox/dom/bindings/EventListenerBinding.cpp
15 	xul.dll 	mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent**, mozilla::dom::EventTarget*, nsEventStatus*) 	dom/events/EventListenerManager.cpp
16 	xul.dll 	mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) 	dom/events/EventDispatcher.cpp
17 	xul.dll 	mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*) 	dom/events/EventDispatcher.cpp

Comment 10

[u279076]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #8)
> Apparently shutdownhang crashes get their signatures generated in a
> different way. If you click "Show other threads" beneath the crashing thread
> stack you'll see in Thread 0 (the main Gecko thread).

I brought this up in the QA meeting today and KaiRo mentioned that we should get that fixed in the Socorro UI. I've gone ahead and filed bug 1144718 for that purpose.

Comment 11

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

We tried to reproduce the issue today on two separate machines (same as bug 1143866 - Windows 7 x64 and x86) using info from comment 0, but we could not get the crash. Also we have not encountered this during our testing last week. At this point it seems highly unlikely that we could find steps to reproduce this.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.