1042653 - [e10s] Tab crash with Tree Style Tab mozilla::EventDispatcher::Dispatch

Status: VERIFIED FIXED

(Core :: DOM: Content Processes, defect)

Description

[Alice0775 White]

Steps To Reproduce:
1. Enable e10s autostart
2. Install latest Tree Style tab( http://piro.sakura.ne.jp/xul/xpi/nightly/treestyletab.xpi )

4. Restart
5. Open about:home and close other tabs if any
6. Exit browser and restart
7. Middle click Home button to open in new tab
8. Close 1st tab by click x button

Actual Results:
The 1st tab wont close
The 1st and 2nd tabs crash
bp-f94bda0d-fa5f-4c3f-88fe-66f622140723

Expected Results:
The 1st tab should close
Tab should not crash

Comment 1

[Alice0775 White]

Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/274a3f27b497
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140717203733
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ed1736c6367a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140717211032
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=274a3f27b497&tochange=ed1736c6367a

Regressed by:
ed1736c6367a	Bill McCloskey — Bug 950745 - Flag when we're processing urgent messages and disallow certain activities (r=bsmedberg,luke)

Comment 2

[Chris Peterson [:cpeterson]]

Thanks for reporting this crash, Alice! I'm setting the "tracking-e10s" tracking flag to '?' so the e10s team will review the bug at our next triage meeting.

Comment 4

[Simon Sapin (:SimonSapin)]

Turns out I hadn’t tried to close tabs when testing for bug 1042680. I can reproduce this: when clicking the x button to close a tab, sometimes (I haven’t figured out the exact pattern) it closes as expected, but sometimes it doesn’t and the content is replaced with this dialog:

"Tab crashed

Well, this is embarrassing. We tried to display this Web page, but it's not responding.

[x] Tell Mozilla about this crash so they can fix it.

[ Try again ]"

Comment 5

[Wayne Mery (:wsmwk)]

Simon, is this gone for you now that bug 1042587 is fixed (in today's nightly)?

Comment 6

[Simon Sapin (:SimonSapin)]

In Nigthly 34.0a1 (2014-08-06), the crash described in this bug is gone: all tabs close as expected. Closing this. However, the problem initially described in bug 1042587 is still there. Re-opening that.

Comment 7

[Alice0775 White]

(In reply to Simon Sapin (:SimonSapin) from comment #6)
> In Nigthly 34.0a1 (2014-08-06), the crash described in this bug is gone: all
> tabs close as expected. Closing this. However, the problem initially
> described in bug 1042587 is still there. Re-opening that.

Nightly(2014-08-06) build does not include the patch of bug 1042587.


And also I can reproduce the crash in Latest m-c Hourly which includes the patch of bug 1042587.
https://hg.mozilla.org/mozilla-central/rev/afcb3af79d09
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140806203224

Comment 8

[Alice0775 White]

Re-regressed by reland the Bug 950745.
	64226fe74be1	Bill McCloskey —  - Flag when we're processing urgent messages and disallow certain activities (r=bsmedberg,luke)

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Alice0775 White from comment #8)
> Re-regressed by reland the Bug 950745.
> 	64226fe74be1	Bill McCloskey —  - Flag when we're processing urgent messages
> and disallow certain activities (r=bsmedberg,luke)

Ah, yes. I misunderstood the timeline.  Thanks for reopening.


(In reply to Alice0775 White from comment #0)
> Steps To Reproduce:
> ...
> Actual Results:
> The 1st tab wont close
> The 1st and 2nd tabs crash
> bp-f94bda0d-fa5f-4c3f-88fe-66f622140723

 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	nsDocumentViewer::PermitUnloadInternal(bool, bool*, bool*)	layout/base/nsDocumentViewer.cpp
3 	xul.dll	nsDocumentViewer::PermitUnload(bool, bool*)	layout/base/nsDocumentViewer.cpp
4 	xul.dll	NS_InvokeByIndex	xpcom/reflect/xptcall/md/win32/xptcinvoke.cpp
5 	xul.dll	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)	js/xpconnect/src/XPCWrappedNativeJSOps.cpp
6 	mozjs.dll	js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct)	js/src/vm/Interpreter.cpp
7 	mozjs.dll	js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>)	js/src/vm/Interpreter.cpp
8 	mozjs.dll	JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)	js/src/jsapi.cpp
9 	xul.dll	mozilla::jsipc::WrapperAnswer::AnswerCallOrConstruct(unsigned __int64 const&, nsTArray<mozilla::jsipc::JSParam> const&, bool const&, mozilla::jsipc::ReturnStatus*, mozilla::jsipc::JSVariant*, nsTArray<mozilla::jsipc::JSParam>*)	js/ipc/WrapperAnswer.cpp
10 	xul.dll	mozilla::jsipc::PJavaScriptChild::OnCallReceived(IPC::Message const&, IPC::Message*&)	obj-firefox/ipc/ipdl/PJavaScriptChild.cpp

Comment 10

[Alice0775 White]

bp-85677837-b4f5-45a6-99ef-8a0152140807

https://hg.mozilla.org/mozilla-central/rev/afcb3af79d09
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140807030202

Comment 11

[Wayne Mery (:wsmwk)]

bp-4d40798d-730e-47ed-9987-14e4e2140807

... and every tab crashed without touching them ...

Comment 12

[Wayne Mery (:wsmwk)]

I also got 

mozalloc_abort(char const* const) | NS_DebugBreak | mozilla::dom::PBrowser::Transition(mozilla::dom::PBrowser::State, mozilla::ipc::Trigger, mozilla::dom::PBrowser::State*)
bp-3b0ba830-3ad3-43b7-9983-71f3d2140807

 0 	mozalloc.dll	mozalloc_abort(char const* const)	memory/mozalloc/mozalloc_abort.cpp
1 	xul.dll	NS_DebugBreak	xpcom/base/nsDebugImpl.cpp
2 	xul.dll	mozilla::dom::PBrowser::Transition(mozilla::dom::PBrowser::State, mozilla::ipc::Trigger, mozilla::dom::PBrowser::State*)	obj-firefox/ipc/ipdl/PBrowser.cpp
3 	xul.dll	mozilla::dom::PBrowserChild::SendRemotePaintIsReady()	obj-firefox/ipc/ipdl/PBrowserChild.cpp
4 	xul.dll	mozilla::layers::CompositorChild::RecvRemotePaintIsReady()	gfx/layers/ipc/CompositorChild.cpp
5 	xul.dll	mozilla::layers::PCompositorChild::OnMessageReceived(IPC::Message const&)	obj-firefox/ipc/ipdl/PCompositorChild.cpp
6 	xul.dll	mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&)	ipc/glue/MessageChannel.cpp
7 	xul.dll	mozilla::ipc::MessageChannel::OnMaybeDequeueOne()	ipc/glue/MessageChannel.cpp
8 	xul.dll	RunnableMethod<`anonymous namespace'::PreallocatedProcessManagerImpl, void ( A0x633de4ce::PreallocatedProcessManagerImpl::*)(void), Tuple0>::Run()	ipc/chromium/src/base/task.h
9 	xul.dll	MessageLoop::RunTask(Task*)	ipc/chromium/src/base/message_loop.cc

Comment 13

[Alice0775 White]

Progression window(m-i)
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/64717933c727
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140815152114
Fixed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d368bd458f99
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140815161716
Fixed pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=64717933c727&tochange=d368bd458f99

Fixed by:
d368bd458f99	Bill McCloskey — Bug 950745 - Back out assertions that are triggering too often

Comment 14

[Bogdan Maris, Desktop QA]

Reproduced the initial crash using an old Nightly (2014-07-23), verified that the issue is fixed using latest Aurora on Windows 7 64bit.