If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

NEW
Unassigned

Status

()

Core
DOM
--
critical
3 years ago
2 years ago

People

(Reporter: ashughes, Unassigned)

Tracking

({crash, steps-wanted})

Trunk
x86
Windows NT
crash, steps-wanted
Points:
---

Firefox Tracking Flags

(firefox36? affected)

Details

(crash signature)

(Reporter)

Description

3 years ago
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)
(Reporter)

Comment 1

3 years ago
[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.
tracking-firefox36: --- → ?

Comment 2

3 years ago
Do we have any reports with sane stack trace?
(Reporter)

Updated

3 years ago
QA Whiteboard: [triaged]
(Reporter)

Comment 3

3 years ago
(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

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

Comment 5

3 years ago
None of the stack traces I looked at have EventDispatcher::Dispatch
(Reporter)

Comment 6

3 years ago
(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

3 years ago
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)
(Reporter)

Comment 9

3 years ago
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
(Reporter)

Comment 10

3 years ago
(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)

Updated

2 years ago
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::EventDi&hellip;
You need to log in before you can comment on or make changes to this bug.