1354810 - Crash in mozilla::dom::Promise::PerformWorkerMicroTaskCheckpoint

Status: RESOLVED FIXED

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

Description

[Wayne Mery (:wsmwk)]

#22 crash for Thunderbird 52.0. Pretty early in 52 cycle, so hard to say whether the rate will continue. But for now it is a topcrash
*Vast majority are jp and CN locales*

earliest I find is bp-db662e67-56b3-43a2-a9ac-07bb72170207 buildid 20170202004014
0 	xul.dll 	mozilla::dom::Promise::PerformWorkerMicroTaskCheckpoint() 	dom/promise/Promise.cpp:581


bp-4a834575-3b4f-4fd2-bd63-a8ac02170405
 0 	xul.dll	mozilla::dom::Promise::PerformWorkerMicroTaskCheckpoint()	dom/promise/Promise.cpp:1081
1 	xul.dll	mozilla::CycleCollectedJSContext::AfterProcessTask(unsigned int)	xpcom/base/CycleCollectedJSContext.cpp:1399
2 	xul.dll	nsThread::ProcessNextEvent(bool, bool*)	xpcom/threads/nsThread.cpp:1232
3 	xul.dll	NS_ProcessNextEvent(nsIThread*, bool)	xpcom/glue/nsThreadUtils.cpp:361

Comment 1

[Wayne Mery (:wsmwk)]

The user above with bp-4a834575-3b4f-4fd2-bd63-a8ac02170405 also crashes with
OOM | large | NS_ABORT_OOM | AppendUTF8toUTF16 | CopyUTF8toUTF16 | nsGenericHTMLElement::GetURIAttr  
bp-e7a2980e-4a00-4f5c-b678-fc50f2170405		
 0 	xul.dll	NS_ABORT_OOM(unsigned int)	xpcom/base/nsDebugImpl.cpp:606
1 	xul.dll	AppendUTF8toUTF16(nsACString_internal const&, nsAString_internal&)	xpcom/string/nsReadableUtils.cpp:334
2 	xul.dll	CopyUTF8toUTF16(nsACString_internal const&, nsAString_internal&)	xpcom/string/nsReadableUtils.cpp:138
3 	xul.dll	nsGenericHTMLElement::GetURIAttr(nsIAtom*, nsIAtom*, nsAString_internal&)	dom/html/nsGenericHTMLElement.cpp:1630
4 	xul.dll	mozilla::dom::HTMLImageElement::GetSrc(nsAString_internal&)	dom/html/HTMLImageElement.cpp:157
5 	xul.dll	mozilla::dom::HTMLImageElementBinding::get_src	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/objdir-tb/dom/bindings/HTMLImageElementBinding.cpp:157
6 	xul.dll	mozilla::dom::GenericBindingGetter(JSContext*, unsigned int, JS::Value*)	dom/bindings/BindingUtils.cpp:2813
7 	xul.dll	mozilla::dom::ForEachHandler(JSContext*, unsigned int, JS::Value*)	dom/bindings/BindingUtils.cpp:3276
8 	xul.dll	xpc::XrayWrapper<js::CrossCompartmentWrapper, xpc::XPCWrappedNativeXrayTraits>::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>)	js/xpconnect/wrappers/XrayWrapper.cpp:2247
9 	xul.dll	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)	js/src/vm/Interpreter.cpp:459
10 	xul.dll	JS::Rooted<JS::GCVector<JS::Value, 8, js::TempAllocPolicy> >::Rooted<JS::GCVector<JS::Value, 8, js::TempAllocPolicy> ><JSContext*, JS::GCVector<JS::Value, 8, js::TempAllocPolicy> >(JSContext* const&, JS::GCVector<JS::Value, 8, js::TempAllocPolicy>&&)	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/objdir-tb/dist/include/js/RootingAPI.h:781
11 	xul.dll	js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>)	js/src/vm/Interpreter.cpp:523
12 	xul.dll	JS::Call	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/objdir-tb/dist/include/jsapi.h:3330
13 	xul.dll	xpc::XrayWrapper<js::CrossCompartmentWrapper, xpc::DOMXrayTraits>::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>)	js/xpconnect/wrappers/XrayWrapper.cpp:2247
14 	xul.dll	xpc::XrayWrapper<js::CrossCompartmentWrapper, xpc::DOMXrayTraits>::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>)	js/xpconnect/wrappers/XrayWrapper.cpp:2247
15 	xul.dll	js::BaseProxyHandler::hasOwn(JSContext*, JS::Handle<JSObject*>, JS::Handle<jsid>, bool*)	js/src/proxy/BaseProxyHandler.cpp:85
16 	xul.dll	JS::GCVector<jsid, 8, js::TempAllocPolicy>::trace(JSTracer*)	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/objdir-tb/dist/include/js/GCVector.h:131

Comment 2

[Makoto Kato [:m_kato]]

There is a few crash by Firefox such as bp-b0372e08-4e0d-4316-80bd-ff2c12170404.  This is Gecko issue.

Comment 3

[Andrew Overholt [:overholt]]

smaug has been doing some work on microtasks so may be interested.

Comment 4

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

This is of course not about microtasks, since Promises don't use microtask.
(PerformWorkerMicroTaskCheck is about something else than microtasks ;) )

comment 1 is OOM.

But the other ones looks like null pointer.
Possible fix coming.

Comment 5

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

Attachment: guess fix

The crashes are offsets from null. And if we for example don't actually have any Promises to run, nothing may keep worker alive.

But guess fix anyhow.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5f578fbf5bde
CycleCollectedJSContext::Get() needs to be null-checked, r=baku

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/5f578fbf5bde

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Looking at crash-stats, doesn't seem likely we're going to know if this patch helps or not until we uplift it to affected branch. Thankfully, it's just some null checks! Please request Aurora/ESR52 approval on this when you get a chance.

Comment 9

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

Comment on attachment 8857885 [details] [diff] [review]
guess fix

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
crashes

User impact if declined: 
crashes

Fix Landed on Version:
55

Risk to taking this patch (and alternatives if risky): 
Should be very safe. Null check.

String or UUID changes made by this patch: 
NA

Comment 10

[Gerry Chang [:gchang]]

Comment on attachment 8857885 [details] [diff] [review]
guess fix

Let's take this in aurora and see if it helps. Aurora54+.

Comment 11

[Iris Hsiao [:ihsiao]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/bd935f8a9fee

Comment 12

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8857885 [details] [diff] [review]
guess fix

Even though there was only 1 instance of this crash on esr52.1, taking it in ESR52 as it's a simple fix.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/e579ef6e8d11

Comment 14

[Wayne Mery (:wsmwk)]

This is now at #72 for TB52.1.0. But many Thunderbird users with this crash also have topcrash signatures associated with 
#20 bug 1353704  mozilla::mailnews::MsgDBReporter::GetPath
#6  bug 1353702  CompareCacheMatchEntry

Note to self, I see this checkin got picked up in 52_1_1esr.  So we will pick this up in our next Thunderbird build.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

The 52.1.1 milestone showing in the hgweb link is misleading - it landed on the default branch which is destined to become 52.2.0 at this point (FIREFOX_ESR_52_1_X_RELBRANCH is where the patches for the 52.1.1 release landed). The version number just isn't bumped until the candidate builds are created.