Open Bug 1143873 Opened 6 years ago Updated 2 years ago

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

Categories

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

x86
Windows NT
defect
Not set
critical

Tracking

()

Tracking Status
firefox36 ? affected

People

(Reporter: u279076, Unassigned)

Details

(Keywords: crash, steps-wanted)

Crash Data

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?
Flags: needinfo?(florin.mezei)
[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.
Do we have any reports with sane stack trace?
QA Whiteboard: [triaged]
(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.
Yes, but I couldn't see any normal stacks.
Looking again...
None of the stack traces I looked at have EventDispatcher::Dispatch
(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?
Right.

Perhaps ted knows why the stack looks like what it does.
Flags: needinfo?(ted)
(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.
Flags: needinfo?(ted)
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
(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.
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.
Flags: needinfo?(florin.mezei)
Crash Signature: [@ shutdownhang | mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*)] → [@ shutdownhang | mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*)] [@ shutdownhang | mozilla::EventDispatche…
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.