Closed Bug 1379518 Opened 7 years ago Closed 7 years ago

Crash in AsyncShutdownTimeout | AddonManager: Waiting for providers to shut down. | EnvironmentAddonBuilder

Categories

(Thunderbird :: General, defect)

Unspecified
All
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 1379831

People

(Reporter: wsmwk, Unassigned)

References

Details

(Keywords: crash, topcrash-thunderbird)

Crash Data

explosive crash for Thunderbird 56.0a1 starting with today's nightly build 20170709030206 - 70+ crashes https://crash-stats.mozilla.com/signature/?product=Thunderbird&release_channel=nightly&signature=AsyncShutdownTimeout%20%7C%20AddonManager%3A%20Waiting%20for%20providers%20to%20shut%20down.%20%7C%20EnvironmentAddonBuilder&date=%3E%3D2017-06-25T23%3A40%3A03.000Z&date=%3C2017-07-09T23%3A40%3A03.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-build_id&_sort=-date&page=1

There has been recent activity in asyncshutdown crashes like
Bug 1378091 - Crash in AsyncShutdownTimeout | profile-before-change | Sqlite.jsm shutdown blocker
Bug 1376874 - Crash in AsyncShutdownTimeout | profile-before-change | Sqlite.jsm shutdown blocker
but but afaict they checked in a few days prior to 20170709030206 

So caused by a comm-central checkin? https://hg.mozilla.org/comm-central/

very few firefox crashes, like bp-9b1e0406-1e36-42fe-bca6-bcff20170709

This bug was filed from the Socorro interface and is 
report bp-4f525aa6-e4d7-4eea-878e-b13a50170709.
=============================================================
 0 	mozglue.dll	mozalloc_abort(char const* const)	memory/mozalloc/mozalloc_abort.cpp:33
1 	xul.dll	NS_DebugBreak	xpcom/base/nsDebugImpl.cpp:407
2 	xul.dll	nsDebugImpl::Abort(char const*, int)	xpcom/base/nsDebugImpl.cpp:147
3 	xul.dll	XPTC__InvokebyIndex	xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_64.asm:97
4 		@0x1d783b186ff	
5 	xul.dll	nsTArray_Impl<BuildTextRunsScanner::MappedFlow, nsTArrayInfallibleAllocator>::AppendElements<nsTArrayInfallibleAllocator>(unsigned __int64)	C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/objdir-tb/dist/include/nsTArray.h:1691
6 	xul.dll	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)	js/xpconnect/src/XPCWrappedNative.cpp:1282
7 	xul.dll	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:966
8 	xul.dll	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)	js/src/vm/Interpreter.cpp:470
9 	xul.dll	Interpret	js/src/vm/Interpreter.cpp:3060
10 	xul.dll	js::RunScript(JSContext*, js::RunState&)	js/src/vm/Interpreter.cpp:410
11 	xul.dll	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)	js/src/vm/Interpreter.cpp:488
12 	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:534
13 	xul.dll	js::Wrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&)	js/src/proxy/Wrapper.cpp:169
14 	xul.dll	js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&)	js/src/proxy/CrossCompartmentWrapper.cpp:359
15 	xul.dll	js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&)	js/src/proxy/Proxy.cpp:481
16 	xul.dll	js::proxy_Call(JSContext*, unsigned int, JS::Value*)	js/src/proxy/Proxy.cpp:741
17 	xul.dll	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)	js/src/vm/Interpreter.cpp:452
18 	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:534
19 	xul.dll	PromiseReactionJob	js/src/builtin/Promise.cpp:1001
20 	xul.dll	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)	js/src/vm/Interpreter.cpp:470
21 	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:534
22 	xul.dll	JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)	js/src/jsapi.cpp:2948
23 	xul.dll	mozilla::dom::LifecycleCreatedCallback::Call(JSContext*, JS::Handle<JS::Value>, mozilla::ErrorResult&)	C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/objdir-tb/dom/bindings/WebComponentsBinding.cpp:474
24 	xul.dll	mozilla::dom::PromiseJobCallback::Call(mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JSCompartment*)	C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/objdir-tb/dist/include/mozilla/dom/PromiseBinding.h:89
25 	xul.dll	mozilla::PromiseJobRunnable::Run()	xpcom/base/CycleCollectedJSContext.cpp:209
26 	xul.dll	mozilla::dom::Promise::PerformMicroTaskCheckpoint()	dom/promise/Promise.cpp:536
27 	xul.dll	mozilla::CycleCollectedJSContext::AfterProcessTask(unsigned int)	xpcom/base/CycleCollectedJSContext.cpp:362
28 	xul.dll	XPCJSContext::AfterProcessTask(unsigned int)	js/xpconnect/src/XPCJSContext.cpp:1007
29 	xul.dll	nsThread::ProcessNextEvent(bool, bool*)	xpcom/threads/nsThread.cpp:1453
30 	xul.dll	XPTC__InvokebyIndex	xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_64.asm:97
31 		@0x0	
32 	xul.dll	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)	js/xpconnect/src/XPCWrappedNative.cpp:1282
33 	xul.dll	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:966
34 		@0x1f8fd9bc174
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #0)
> So caused by a comm-central checkin? https://hg.mozilla.org/comm-central/
Highly unlikely. More likely that we're exercising M-C code in a way they don't expect.
it's regressing in firefox as well with 56.0a1 build 20170709030204. could it be related to bug 1358907?
Flags: needinfo?(aswan)
This is telemetry never resolving its shutdown blocker.  Prior to bug 1358907, telemetry queried the xpi database during startup, with this bug it waits for the xpi database to be loaded some time after startup.  The code that ensures that we do load the xpi database is unfortunately messy:
http://searchfox.org/mozilla-central/rev/b7e531410ebc1c7d74a78e86a894e69608db318c/toolkit/mozapps/extensions/internal/XPIProvider.jsm#2273-2308

Perhaps Thunderbird needs to add yet another case there?
Flags: needinfo?(aswan)
bp-41f1734c-eecc-4074-9163-a77450170709 writes "crash on every shutdown".  But surely our crash numbers would be much higher if every user was crashing on shutdown? I just tested nightly and no crash no shutdown.
See also bug 1379831 which involves using -silent.
See Also: → 1379994
Bug 1379831 should address this, should we dupe it or do you want to track this separately for TB?
No need to track this separately. We're just building TB 55 beta 2, so too late for that. It will go into TB 56 beta.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
THis Thunderbird topcrash is gone in July 14 build.
Status: RESOLVED → VERIFIED
Confirmed also no crash after Jul 14 build, on the x64 release.
You need to log in before you can comment on or make changes to this bug.