#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

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

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

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

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.

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.

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

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 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 on attachment 8857885 [details] [diff] [review] guess fix Let's take this in aurora and see if it helps. Aurora54+.

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.

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.

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.