1559448 - Shutdown crash [@ AsyncShutdownTimeout | profile-change-teardown | Extension shutdown: [e-mail] ]. Primary password conflict with add-ons startup

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: General, defect)

Description

[Stefan Sitter [:ssitter]]

I have been testing around with Thunderbird 68 Beta / Lightning 7.0 Beta on Windows 10. Crash reporter was triggered and the following report was submitted:
https://crash-stats.mozilla.com/report/index/2d9ca6b9-1251-455c-9229-fd3dd0190613

Search shows about 128 crashes with the same signature in the last 6 months https://crash-stats.mozilla.com/search/?signature=%3DAsyncShutdownTimeout%20%7C%20profile-change-teardown%20%7C%20Extension%20shutdown%3A%20wetransfer%40extensions.thunderbird.net&product=Thunderbird&date=%3E%3D2018-12-14T16%3A44%3A00.000Z&date=%3C2019-06-14T16%3A44%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

This extension is shown neither in Add-ons Manager > Extensions nor Troubleshooting Information > Extensions. I don't need it and don't want unnecessary extensions that cause Thunderbird crashes. How to disable this feature / extension?

Comment 1

[Geoff Lankow (:darktrojan)]

This isn't related specifically to the WeTransfer extension, that just happens to show up in the signature.

This extension is shown neither in Add-ons Manager > Extensions nor Troubleshooting Information > Extensions. I don't need it and don't want unnecessary extensions that cause Thunderbird crashes. How to disable this feature / extension?

This is a Thunderbird built-in feature that just happens to be implemented as an extension. It's not an optional part of Thunderbird.

Comment 2

[Wayne Mery (:wsmwk)]

perhaps this signature is the same issue AsyncShutdownTimeout | profile-change-teardown | Extension shutdown: {e2fda1a4-762b-4020-b5ad-a41df1933103} (this is the calendar addon) bp-b3927b74-32cb-4c35-afc2-fc4df0191019 Version 66.0b0 Build ID 20190209112700 (2019-02-09)

If it is, then this is #20 crash for Thunderbird. But bug 1464938 also suggest that one contributing factor to crashing is slow shutdown?

Comment 3

[Wayne Mery (:wsmwk)]

Stefan, are you crashing frequently?

Comment 4

[Stefan Sitter [:ssitter]]

I don't see crashes.

Comment 5

[Wayne Mery (:wsmwk)]

bp-26338d5b-16e4-439b-8ca7-344dc0200117 from https://support.mozilla.org/en-US/questions/1277551 where the user also experiences "frequent hangs, with it shown as "not responding", for long chunks of time. Sometimes it's after I, you know, DO SOMETHING, such as typing a few letters into an email composition, or, maybe, click on an email to read... sometimes, occasionally, there seems to be no reason at all that I can see.)"

It's unclear we're going to find salvation via bug 1464938. There are many other addons cited in crashes https://crash-stats.mozilla.com/search/?signature=~AsyncShutdownTimeout%20%7C%20profile-change-teardown&product=Thunderbird&date=%3E%3D2020-01-06T13%3A21%3A00.000Z&date=%3C2020-01-20T13%3A21%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature but wetransfer is certainly the most.

Perhaps this is from something like expunge on shutdown enabled?

Comment 6

[Robert Hartmann]

On Windows 10 home 64bit:

Updating TB nightly 64bit to 82.0a1 BuildID 20200908085134
=> Thunderbird 82.0a1 Crash Report [@ AsyncShutdownTimeout | profile-change-teardown | Extension shutdown: [e-mail] ]
=> bp-c7effdcb-15f8-4dbb-8bc2-739750200908

Updating TB nightly 32bit to 82.0a1 BuildID 20200908085134
=> Thunderbird 82.0a1 Crash Report [@ AsyncShutdownTimeout | profile-change-teardown | Extension shutdown: [e-mail] ]
=> bp-6ffed27e-3652-4743-971d-c343d0200908

both with different stack traces.

==================================================
32bit stack trace:

Crashing Thread (0)
Frame Module Signature Source Trust
0 mozglue.dll mozalloc_abort(char const* const) memory/mozalloc/mozalloc_abort.cpp:33 context
1 xul.dll NS_DebugBreak(unsigned int, char const*, char const*, char const*, int) xpcom/base/nsDebugImpl.cpp:437 cfi
2 xul.dll nsDebugImpl::Abort(char const*, int) xpcom/base/nsDebugImpl.cpp:134 cfi
3 xul.dll NS_InvokeByIndex cfi
4 xul.dll static XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) js/xpconnect/src/XPCWrappedNative.cpp:1141 frame_pointer
5 xul.dll XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) js/xpconnect/src/XPCWrappedNativeJSOps.cpp:946 cfi
6 xul.dll js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) js/src/vm/Interpreter.cpp:599 cfi
7 xul.dll Interpret(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:3336 cfi
8 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:468 cfi
9 xul.dll js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) js/src/vm/Interpreter.cpp:636 cfi
10 xul.dll js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) js/src/vm/Interpreter.cpp:681 cfi
11 xul.dll PromiseReactionJob(JSContext*, unsigned int, JS::Value*) js/src/builtin/Promise.cpp:1902 cfi
12 xul.dll js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) js/src/vm/Interpreter.cpp:599 cfi
13 xul.dll js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) js/src/vm/Interpreter.cpp:681 cfi
14 xul.dll JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) js/src/jsapi.cpp:2831 cfi
15 xul.dll mozilla::dom::FinalizationRegistryCleanupCallback::Call(mozilla::dom::BindingCallContext&, JS::Handle<JS::Value>, mozilla::ErrorResult&) dom/bindings/FinalizationRegistryBinding.cpp:22 cfi
16 xul.dll mozilla::PromiseJobRunnable::Run(mozilla::AutoSlowOperation&) xpcom/base/CycleCollectedJSContext.cpp:211 cfi
17 xul.dll mozilla::CycleCollectedJSContext::PerformMicroTaskCheckPoint(bool) xpcom/base/CycleCollectedJSContext.cpp:646 cfi
18 xul.dll mozilla::CycleCollectedJSContext::AfterProcessTask(unsigned int) xpcom/base/CycleCollectedJSContext.cpp:461 cfi
19 xul.dll XPCJSContext::AfterProcessTask(unsigned int) js/xpconnect/src/XPCJSContext.cpp:1407 cfi
20 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1271 cfi
21 xul.dll NS_InvokeByIndex cfi
22 xul.dll static XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) js/xpconnect/src/XPCWrappedNative.cpp:1141 frame_pointer
23 xul.dll XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) js/xpconnect/src/XPCWrappedNativeJSOps.cpp:946 cfi
24 @0x2d170efe cfi
25 @0x1d0c7527 frame_pointer
26 @0x2d15071a frame_pointer
27 xul.dll js::jit::EnterBaselineInterpreterAtBranch(JSContext*, js::InterpreterFrame*, unsigned char*) js/src/jit/BaselineJIT.cpp:188 frame_pointer
28 xul.dll Interpret(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:2237 cfi
29 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:468 cfi
30 xul.dll js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) js/src/vm/Interpreter.cpp:636 cfi
31 xul.dll js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) js/src/vm/Interpreter.cpp:681 cfi
32 xul.dll JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) js/src/jsapi.cpp:2768 cfi
33 xul.dll nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*) js/xpconnect/src/XPCWrappedJSClass.cpp:963 cfi
34 xul.dll PrepareAndDispatch(nsXPTCStubBase*, unsigned int, unsigned int*, unsigned int*) xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:79 cfi
35 xul.dll SharedStub() xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:98 cfi
36 xul.dll nsObserverList::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverList.cpp:70 cfi

===============================================

64bit stack trace:

Crashing Thread (0)
Frame Module Signature Source Trust
0 mozglue.dll mozalloc_abort(char const* const) memory/mozalloc/mozalloc_abort.cpp:33 context
1 xul.dll NS_DebugBreak(unsigned int, char const*, char const*, char const*, int) xpcom/base/nsDebugImpl.cpp:437 cfi
2 xul.dll nsDebugImpl::Abort(char const*, int) xpcom/base/nsDebugImpl.cpp:134 cfi
3 xul.dll XPTC__InvokebyIndex cfi
4 @0x1585074a57f cfi
5 xul.dll truncf scan
6 xul.dll truncf scan
7 xul.dll static XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) js/xpconnect/src/XPCWrappedNative.cpp:1141 scan
8 xul.dll XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) js/xpconnect/src/XPCWrappedNativeJSOps.cpp:946 cfi
9 xul.dll js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) js/src/vm/Interpreter.cpp:599 cfi
10 xul.dll Interpret(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:3336 cfi
11 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:468 cfi
12 xul.dll js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) js/src/vm/Interpreter.cpp:636 cfi
13 xul.dll js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) js/src/vm/Interpreter.cpp:681 cfi
14 xul.dll PromiseReactionJob(JSContext*, unsigned int, JS::Value*) js/src/builtin/Promise.cpp:1902 cfi
15 xul.dll js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) js/src/vm/Interpreter.cpp:599 cfi
16 xul.dll js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) js/src/vm/Interpreter.cpp:681 cfi
17 xul.dll JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) js/src/jsapi.cpp:2831 cfi
18 xul.dll mozilla::dom::FinalizationRegistryCleanupCallback::Call(mozilla::dom::BindingCallContext&, JS::Handle<JS::Value>, mozilla::ErrorResult&) dom/bindings/FinalizationRegistryBinding.cpp:22 cfi
19 xul.dll mozilla::PromiseJobRunnable::Run(mozilla::AutoSlowOperation&) xpcom/base/CycleCollectedJSContext.cpp:211 cfi
20 xul.dll mozilla::CycleCollectedJSContext::PerformMicroTaskCheckPoint(bool) xpcom/base/CycleCollectedJSContext.cpp:646 cfi
21 xul.dll mozilla::CycleCollectedJSContext::AfterProcessTask(unsigned int) xpcom/base/CycleCollectedJSContext.cpp:461 cfi
22 xul.dll XPCJSContext::AfterProcessTask(unsigned int) js/xpconnect/src/XPCJSContext.cpp:1407 cfi
23 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1271 cfi
24 xul.dll XPTC__InvokebyIndex cfi
25 xul.dll truncf cfi
26 xul.dll truncf scan
27 xul.dll truncf scan
28 xul.dll static XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) js/xpconnect/src/XPCWrappedNative.cpp:1141 scan
29 xul.dll XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) js/xpconnect/src/XPCWrappedNativeJSOps.cpp:946 cfi
30 @0x300f352fbf9 cfi

Comment 7

[Robert Hartmann]

Updating TB daily 64bit to 82.0a1 Build 20200914104010 : crashed after click on resubmit button: bp-a25d46f4-5509-4dd5-b69d-296670200914
on 32bit update to to 82.0a1 Build 20200914104010: bp-1ffc26ce-4fd8-49f7-b76a-d049c0200914

Comment 8

[Robert Hartmann]

Simpler way to reproduce:
Start TB daily in 32bit or 64bit Version on Windows 10 64bit - and just close TB main window ... wait a bit ... and crash.

reproducible: allways with
Version 82.0a1
Build ID 20200918212046

32bit-crash : bp-3a384001-fe9e-4121-9abd-8a16c0200919
64bit-crash : bp-136c0d19-354e-499b-897f-2e7080200919

Comment 9

[Robert Hartmann]

Reproducible with
Product Thunderbird
Release Channel nightly
Version 83.0a1
Build ID 20200922082006 (2020-09-22)

Thunderbird 83.0a1 Crash Report [@ AsyncShutdownTimeout | profile-change-teardown | Extension shutdown: [e-mail] ]

32bit crash : bp-f5728164-216f-4f8e-a14d-5aae20200922
64bit crash : bp-3078bd25-dfd3-472d-9728-678ee0200922

Comment 10

[Wayne Mery (:wsmwk)]

Robert, can you make version 78 crash?

Now a topcrash for nightly - 6 signatures in the top 10.

BUT, the crash rate has decreased in the past 6 months by roughly half. Seems to be because 78.* release has zero crashes with teardown in the signature - perhaps the signature morphed.

Comment 11

[Christian Riechers]

TB82.0b1 on Linux
The crash happens for me with TB82.0b1 simply when shutting down TB. Happens every time.
bp-ee07b487-1de9-46b5-b045-26c4f0200926
bp-c7dc076a-fef7-42f4-a4f3-3af100200926
bp-a1941f71-9aa2-4379-9d0f-302190200926

Comment 12

[Wayne Mery (:wsmwk)]

And to go with comment 10 and 11, we have a big increase with version 82.
See https://crash-stats.mozilla.org/signature/?product=Thunderbird&release_channel=beta&signature=AsyncShutdownTimeout%20%7C%20profile-change-teardown%20%7C%20Extension%20shutdown%3A%20wetransfer%40extensions.thunderbird.net&date=%3E%3D2020-06-26T23%3A06%3A00.000Z&date=%3C2020-09-26T23%3A06%3A00.000Z#graphs

Comment 13

[Magnus Melin [:mkmelin]]

I don't have any clues how to fix this. Rough guess is during shutdown there is some unfinished operation, and things get teared down in the wrong order internally.

Comment 14

[Robert Hartmann]

(In reply to Wayne Mery (:wsmwk) from comment #10)

Robert, can you make version 78 crash?

Well, no - not that type of crash.
But, yes, in TB 78 there was a crash for me while viewing an attached PDF-file.
see bug 1461724 comment 29 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1461724#c29 )
I think that those (FF and TB) crash is not related to this crash.

Comment 15

[Robert Hartmann]

(In reply to Robert Hartmann from comment #14)

(In reply to Wayne Mery (:wsmwk) from comment #10)

Robert, can you make version 78 crash?

Well, no - not that type of crash.
But, yes, in TB 78 there was a crash for me while viewing an attached PDF-file.
see bug 1461724 comment 29 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1461724#c29 )
I think that those (FF and TB) crash is not related to this crash.

And on an other Windows System I got
Thunderbird 78.3.1 Crash Report [@ shutdownhang | mozilla::AppWindow::ShowModal ]
see bug 1669836 https://bugzilla.mozilla.org/show_bug.cgi?id=1669836

Comment 16

[Robert Hartmann]

Firefox have "Shutdown problem in workers" ( bug 1435343 ) and had "Investigate the Worker/ServiceWorker shutdown crashes: RuntimeService" ( bug 1664386 ), and on bug 1664386 comment 15 there is written :

    "
     https://hg.mozilla.org/integration/autoland/rev/186ca9e93e1d
     Avoid any possibility of infinite process hangs due to workers hanging on shutdown and add chrome worker information to reports r=dom-  workers-and-storage-reviewers,asuth 
    "

@Magnus Melin:
Maybe some changes like that can help in this TB "Shutdown crash [@ AsyncShutdownTimeout | profile-change-teardown | Extension shutdown: [e-mail] ]" to get some more information?

Comment 17

[erik]

82.0b2(64)
Same problem here.
I see wetransfer in the error log:
Never used the we-transfer option.
I can add we-transfer in the configuration. I see a silly picture.
But there is no set up.

Comment 18

[Magnus Melin [:mkmelin]]

Bug 1464938 comment 51 lists some things that could be done. Unclear if they would fix this bug or not

Comment 19

[Robert Hartmann]

changed stack traces ...

=> TB daily (64bit) 84.0a1 (2020-10-20)
bp-2c1c3cbf-58df-489e-a6dc-2e1b10201020

    Frame 	Module 	Signature 	Source 	Trust
         0 	mozglue.dll 	mozalloc_abort(char const* const) 	memory/mozalloc/mozalloc_abort.cpp:33 	context
         1 	xul.dll 	NS_DebugBreak(unsigned int, char const*, char const*, char const*, int) 	xpcom/base/nsDebugImpl.cpp:435 	cfi
         2 	xul.dll 	nsDebugImpl::Abort(char const*, int) 	xpcom/base/nsDebugImpl.cpp:134 	cfi
         3 	xul.dll 	XPTC__InvokebyIndex 		cfi
         4 		@0x22ffc83df0f 		cfi
         5 	xul.dll 	mozilla::dom::MessageSender_Binding::CreateInterfaceObjects(JSContext*, JS::Handle<JSObject*>, mozilla::dom::ProtoAndIfaceCache&, bool) 	dom/bindings/MessageManagerBinding.cpp:4870 	scan
         6 		@0x22ff05f7c1f 		cfi
         7 	xul.dll 	truncf 		scan
         8 	xul.dll 	js::CheckedUnwrapDynamic(JSObject*, JSContext*, bool) 	js/src/proxy/Wrapper.cpp:408 	scan

=> TB daily (32bit) 84.0a1 (2020-10-20)
bp-f23f914a-d322-4005-bf22-7a61c0201020

         Frame 	Module 	Signature 	Source 	Trust
         0 	mozglue.dll 	mozalloc_abort(char const* const) 	memory/mozalloc/mozalloc_abort.cpp:33 	context
         1 	xul.dll 	NS_DebugBreak(unsigned int, char const*, char const*, char const*, int) 	xpcom/base/nsDebugImpl.cpp:435 	cfi
         2 	xul.dll 	nsDebugImpl::Abort(char const*, int) 	xpcom/base/nsDebugImpl.cpp:134 	cfi
         3 	xul.dll 	NS_InvokeByIndex 		cfi
         4 	xul.dll 	static XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 	js/xpconnect/src/XPCWrappedNative.cpp:1142 	frame_pointer
         5 	xul.dll 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:925 	cfi
         6 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) 	js/src/vm/Interpreter.cpp:598 	cfi
         7 	xul.dll 	Interpret(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp:3336 	cfi
         8 	xul.dll 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp:476 	cfi
         9 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) 	js/src/vm/Interpreter.cpp:635 	cfi
         10 	xul.dll 	js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) 	js/src/vm/Interpreter.cpp:680 	cfi
         11 	xul.dll 	PromiseReactionJob(JSContext*, unsigned int, JS::Value*) 	js/src/builtin/Promise.cpp:1903 	cfi
         12 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) 	js/src/vm/Interpreter.cpp:598 	cfi
         13 	xul.dll 	js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) 	js/src/vm/Interpreter.cpp:680 	cfi
         14 	xul.dll 	JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) 	js/src/jsapi.cpp:2829 	cfi
         15 	xul.dll 	mozilla::dom::FinalizationRegistryCleanupCallback::Call(mozilla::dom::BindingCallContext&, JS::Handle<JS::Value>, mozilla::ErrorResult&) 	dom/bindings/FinalizationRegistryBinding.cpp:24 	cfi
         16 	xul.dll 	mozilla::PromiseJobRunnable::Run(mozilla::AutoSlowOperation&) 	xpcom/base/CycleCollectedJSContext.cpp:211 	cfi
         17 	xul.dll 	mozilla::CycleCollectedJSContext::PerformMicroTaskCheckPoint(bool) 	xpcom/base/CycleCollectedJSContext.cpp:646 	cfi
         18 	xul.dll 	mozilla::CycleCollectedJSContext::AfterProcessTask(unsigned int) 	xpcom/base/CycleCollectedJSContext.cpp:461 	cfi
         19 	xul.dll 	XPCJSContext::AfterProcessTask(unsigned int) 	js/xpconnect/src/XPCJSContext.cpp:1467 	cfi
         20 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1233 	cfi
         21 	xul.dll 	NS_InvokeByIndex 		cfi
         22 	xul.dll 	static XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 	js/xpconnect/src/XPCWrappedNative.cpp:1142 	frame_pointer
         23 	xul.dll 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:925 	cfi
         24 		@0x2c3f01fe 		cfi
         25 		@0x21d354d7 		frame_pointer
         26 		@0x2c3e073a 		frame_pointer
         27 	xul.dll 	js::jit::EnterBaselineInterpreterAtBranch(JSContext*, js::InterpreterFrame*, unsigned char*) 	js/src/jit/BaselineJIT.cpp:218 	frame_pointer
         28 	xul.dll 	Interpret(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp:2237 	cfi
         29 	xul.dll 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp:476 	cfi
         30 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) 	js/src/vm/Interpreter.cpp:635 	cfi
         31 	xul.dll 	js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) 	js/src/vm/Interpreter.cpp:680 	cfi
         32 	xul.dll 	JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) 	js/src/jsapi.cpp:2766 	cfi
         33 	xul.dll 	nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*) 	js/xpconnect/src/XPCWrappedJSClass.cpp:970 	cfi
         34 	xul.dll 	PrepareAndDispatch(nsXPTCStubBase*, unsigned int, unsigned int*, unsigned int*) 	xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:79 	cfi
         35 	xul.dll 	SharedStub() 	xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:98 	cfi
         36 	xul.dll 	nsObserverList::NotifyObservers(nsISupports*, char const*, char16_t const*) 	xpcom/ds/nsObserverList.cpp:70 	cfi

Comment 21

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #18)

Bug 1464938 comment 51 lists some things that could be done. Unclear if they would fix this bug or not

We're getting clobbered by shutdowncrash signatures - 67 crash signatures containing wetransfer alone with 83 beta. So it would be great if we could make any progress. But there is nothing, zero progress, coming out of m-c in Bug 1464938 and friends.

Comment 22

[Robert Hartmann]

Maybe this bug and bug 1664586 (TB tray notification) are connected together:

bp-90114848-75e0-4730-8653-c81a00201119
85.0a1 (2020-11-19) (64-bit)
=> open Activity Manager
=> write Mail to own IMAP
=> close TB main window
=> Activity Manager didn't close, TaskSymbol "new Mail" stay visible

=> crash happen after closing Activity Manager window
"new Mail" symbol is shown in taskbar

Foreach TB close crash (while having new Mail) there is a living "new mail" notification icon in Windows 10 20H2 64bit

Comment 23

[Robert Hartmann]

So maybe the Window-Event-Message-Loop of main window doesn't tell its child windows and background tasks like (folder compacting, doing indexing, IMAP fetch of multiple or big mails) ant tray icons, that it it time to stop. I had a similar problem in an own multithreated program: My solution was, creating an invisable window for my working thread with an own Window-Event-Message-Loop for that by main-window unclosable thread.

Comment 24

[Robert Hartmann]

(In reply to Robert Hartmann from comment #22)

Maybe this bug and bug 166486 (TB tray notification) are connected together:

sorry mistyped the number: it should be bug 1664586 - the number 5 between 4 and 8 was missing.

bp-90114848-75e0-4730-8653-c81a00201119
85.0a1 (2020-11-19) (64-bit)
=> open Activity Manager
=> write Mail to own IMAP
=> close TB main window
=> Activity Manager didn't close, TaskSymbol "new Mail" stay visible

=> crash happen after closing Activity Manager window
"new Mail" symbol is shown in taskbar

Foreach TB close crash (while having new Mail) there is a living "new mail" notification icon in Windows 10 20H2 64bit

Comment 26

[Robert Hartmann]

steps to reproduce

1. Start TB (Masterpassword enabled)
2. Check for mails (IMAP) or wait some time less than a minute without doing something.
3. Close TB
   => Crash.

TB 86.0a1 daily 64bit (Build ID 20201223095856)
bp-8f64231f-cf5b-4db4-905a-761d20201223
https://crash-stats.mozilla.org/report/index/8f64231f-cf5b-4db4-905a-761d20201223

TB 85.0b2 beta 64bit (Build-ID 20201222142912)
bp-b67cac2c-2533-4477-b621-ba3070201223
https://crash-stats.mozilla.org/report/index/b67cac2c-2533-4477-b621-ba3070201223

TB 78.6.0 release 64bit (Build-ID 20201211152611)
no close crash

TB 86.0a1 daily 32bit (Build ID 20201223095856)
bp-b90e8626-ba38-4de9-9068-271ad0201223
https://crash-stats.mozilla.org/report/index/b90e8626-ba38-4de9-9068-271ad0201223

TB 85.0b2 beta 32bit (Build-ID 20201222142912)
bp-679993cd-0e5f-4ad1-85b8-4a39e0201223
https://crash-stats.mozilla.org/report/index/679993cd-0e5f-4ad1-85b8-4a39e0201223

TB 78.6.0 release 32bit (Build-ID 20201211152611)
no close crash

Comment 27

[Wayne Mery (:wsmwk)]

Attachment: Sept 2020 rate increase

(In reply to Wayne Mery (:wsmwk) from comment #12)

And to go with comment 10 and 11, we have a big increase with version 82.
See https://crash-stats.mozilla.org/signature/?product=Thunderbird&release_channel=beta&signature=AsyncShutdownTimeout%20%7C%20profile-change-teardown%20%7C%20Extension%20shutdown%3A%20wetransfer%40extensions.thunderbird.net&date=%3E%3D2020-06-26T23%3A06%3A00.000Z&date=%3C2020-09-26T23%3A06%3A00.000Z#graphs

This graph is more starkly shows the increase more starkly at the release of 82 beta on Sept 26 - https://crash-stats.mozilla.org/signature/?product=Thunderbird&release_channel=beta&release_channel=nightly&signature=AsyncShutdownTimeout%20%7C%20profile-change-teardown%20%7C%20Extension%20shutdown%3A%20wetransfer%40extensions.thunderbird.net&date=%3E%3D2020-07-07T03%3A49%3A00.000Z&date=%3C2021-01-07T03%3A49%3A00.000Z#graphs

And I reconfirm that 82 nightly crashes begin 2020-09-08, exactly the time of Robert's comment 6.

IMO the cause must be a checkin in the 24 hours prior to building that nightly

• https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2020-09-07+01%3A01%3A33&enddate=2020-09-08+09%3A02%3A20
• https://hg.mozilla.org/comm-central/pushloghtml?startdate=2020-09-07+01%3A01%3A33&enddate=2020-09-08+09%3A02%3A20

Comment 28

[Magnus Melin [:mkmelin]]

A wild guess, but maybe it's printing related (printing started working at that point, partly.)

Comment 29

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #28)

A wild guess, but maybe it's printing related (printing started working at that point, partly.)

Yes, notable recently fixed bugs are:

• Bug 1663140 - Print preview displays blank pages for pdf documents
• Bug 1663283 - Bug 1636728 broke printing nested iframes.
• Bug 1636728 - Support changing print preview settings without recloning the print preview document
• also Bug 1662090 - Crash in [@ mozilla::dom::Document::CloneDocHelper]

Comment 30

[erik]

Clear 'master password' and the bug is gone after the 2nd restart.

Also tested in Windows 10 sandbox. TB85.0b3/64
1 IMAP account and only the 'master password' set.
The rest of TB is default.
confirms the problem.

Comment 31

[Wayne Mery (:wsmwk)]

(In reply to Robert Hartmann from comment #26)

steps to reproduce

1. Start TB (Masterpassword enabled)
2. Check for mails (IMAP) or wait some time less than a minute without doing something.
3. Close TB
   => Crash.

These steps match bug 1149287

Comment 32

[Robert Hartmann]

(In reply to Wayne Mery (:wsmwk) from comment #31)

(In reply to Robert Hartmann from comment #26)

steps to reproduce

1. Start TB (Masterpassword enabled)
2. Check for mails (IMAP) or wait some time less than a minute without doing something.
3. Close TB
   => Crash.

These steps match bug 1149287

The crash (only) happens on Windows 10 (64bit) when master password is set:
TB Daily 32 bit : Version=87.0a1 BuildID=20210131105644 bp-6d12877c-1d66-47bf-b8c5-331800210131
TB Daily 64 bit : Version=87.0a1 BuildID=20210131105644 bp-552880fb-5af9-4315-ac16-d6c0e0210131
TB beta 32 bit : Version=86.0 BuildID=20210128005905 bp-e3dc336a-52c4-41d3-affe-1d7d50210131
TB beta 64 bit : Version=86.0 BuildID=20210128005905 bp-5cff791e-b54b-428a-9b59-cab580210131

if no master password is set, than no crash happend.

TB updater works for beta and daily without restart crash if no master password is set.

Comment 33

[pbrandao]

My simple experimentation in the hope that provides some clues

Using:

• windows 10.0.19042 (64b)
• TB 86.0b1 (64b)
• created clean profile and added calendars and email from Google
• using master password
  The reported crash occurs.

If:

• remove file C:\Program Files\Mozilla Thunderbird\features\[e-mail]
• remove entry for WeTransfer in user data: extensions.json
  • just removing the entry in the json file does not stop the extension from being loaded and crashing TB on exit

The crash did not occur. Master password is still in use.

Additional info
When the WeTransfer addon is active TB has 3 running processes. One of the processes has a thread waiting on Net IO since starting TB.

• killing the thread with Windows Task Manager "avoids" the crash. It can be killed immediately on starting TB (it did not seem to have impact on TB) or after closing TB (before the crash is detected).

My 2cs
Without the extension active there are only 2 processes running. Exiting is quick and without crashing.

Comment 34

[pbrandao]

Adding to #33
I tried with a more complete mail profile (several accounts and GB of email). This time a "dirty" profile (created new profile and copied content from old profile except Imap-Mail folder).

• Removed the C:\Program Files\Mozilla Thunderbird\features\[e-mail] file
• Master password enabled.

When starting there were 3 processes (one I think on Net IO). This (I guess) is to be expected as TB was transferring all email content.
On close there was a crash also but this time with a different profile bp-fc86d8e5-298e-404a-91d8-aac740210204 .
The extensions mentioned did not respond well to disabling them (had to click twice to disable and even so they did not go to the "disabled" group, only enable/disable switch moved to off). And they were not working on TB 86b1 although supposedly supported.

Starting in safe mode, led to:

• one active process
• mails being downloaded
• no crash on exit

Using safe mode to disable all addons led to:

• problematic addons from above are still enabled
• crash on exit

Comment 35

[Wayne Mery (:wsmwk)]

Can we sort this out based on the excellent work of comment 33 and comment 34?

Comment 37

[Geoff Lankow (:darktrojan)]

I have a theory, it's not much and even if it's proved correct I don't know what to do about it.

• With the primary password enabled, we ask for it early in start-up here. This is Thunderbird-specific code so Firefox wouldn't have the same problem.
• This leads to a prompt window being opened which somehow causes the extensions system to start-up.
• The extensions system isn't ready to start yet, because it's earlier than it should be, and so things fail to begin. For example this error is thrown when the WeTransfer extension tries to do something. NotFoundError: WindowGlobalChild.getActor: No such JSWindowActor 'Conduits' @ ExtensionCommon.jsm:500
• The extensions get stuck in the start-up state and therefore can't shut down.
• Everything gets sick of waiting for them to shut down and crashes.

It seems the WeTransfer extension doesn't work properly if the primary password is enabled, which supports the theory.

CC'ing Kai as he put the password code there and may have some ideas about how to mitigate this.

Comment 38

[Kai Engert (:KaiE:)]

(In reply to Geoff Lankow (:darktrojan) from comment #37)

I have a theory, it's not much and even if it's proved correct I don't know what to do about it.

Are you able to proof the theory? If you can reproduce reliably, you could set the pref to false, to check if that fixes the crash.

Comment 39

[Geoff Lankow (:darktrojan)]

Yeah, that's the cause. I'm going to work out why the add-ons code starts and see if we can prevent it.

Comment 40

[Geoff Lankow (:darktrojan)]

Okay, this is weird. The addons-startup notification that starts things happens before the password prompt (in nsXREDirProvider::DoStartup) which is okay I guess, but moving it to immediately after the prompt, the problems go away. So it's definitely some combination of the two, but I don't know what.

Comment 41

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1559448 - Move Thunderbird primary password prompt earlier in start-up. r?KaiE,#xpcom-reviewers!

Triggering the password prompt after the Add-Ons Manager start-up is causing the latter to fail.

I'm not sure if something needs to be unlocked by the password, or if the existence of the prompt is causing some bad interaction, but prompting slightly earlier appears to fix it.

Comment 42

[Kai Engert (:KaiE:)]

(In reply to Geoff Lankow (:darktrojan) from comment #41)

I'm not sure if something needs to be unlocked by the password, or if the existence of the prompt is causing some bad interaction, but prompting slightly earlier appears to fix it.

It was my original intention to bring up the prompt as early as possible.
The code to bring up the password takes care of triggering init for anything required for the crypto code.

I couldn't tell what's necessary for the UI to work. So the location I had chosen was based on experimenting.
For macOS, I had learned that the existing code was "too early", because some window stuff was not yet initialized.

If you find a better (earlier) place that fixes this bug, and the password prompt still works on Windows and Linux, that's great.
I've just merged your change to esr78 and I'm running your change on my primary Linux system, and it seems to work.

Let's land and get feedback from testers.

Comment 43

[Kai Engert (:KaiE:)]

Attachment: 1559448-esr78-v1.patch

This is a version merged to esr78 which I'm testing locally.

Comment 44

[Kai Engert (:KaiE:)]

(I tried macOS, just to check if the new patch improves the situation. It doesn't. But that's not relevant for the issue here.)

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ed65070d30fb
Move Thunderbird primary password prompt earlier in start-up. r=kaie,xpcom-reviewers,mccr8 DONTBUILD

Comment 46

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/ed65070d30fb

Comment 47

[Robert Hartmann]

as normal user on MS Windows 10, Home, 64bit , Version 20H2 (Build 19042.906)
there is realy no TB close crash, with masterpassword enabled, any more;
tested with:

TB daily 64 bit , 89.0a1 , 20210331093938
TB beta 64 bit , 88.0b1 , 20210322231939
TB release 64 bit , 78.9.0 , 20210322094744

TB daily 32 bit , 89.0a1 , 20210331093938
TB beta 32 bit , 88.0b1 , 20210322231939
TB release 32 bit , 78.9.0 , 20210322094744

Best regards and thanks for bug fixing!

Comment 48

[Ralph Fox]

MS Windows 10 Pro 64-bit. Master Password set in Thunderbird .
I am still seeing this crash in TB beta 64 bit , 88.0b2, 20210330220818.
This happens every time I close Thunderbird beta.

At the same time, I have never seen this crash in TB release version (also with Master Password set).

Comment 49

[Magnus Melin [:mkmelin]]

Should we go ahead and uplift to 78?

Comment 50

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #49)

Should we go ahead and uplift to 78?

Yes, although it very unclear what the impact might be for version 78.

It definitely helped beta - dramatic drop with beta 88 https://crash-stats.mozilla.org/signature/?release_channel=%21release&signature=AsyncShutdownTimeout%20%7C%20profile-change-teardown%20%7C%20Extension%20shutdown%3A%20wetransfer%40extensions.thunderbird.net&date=%3E%3D2021-01-22T12%3A18%3A00.000Z&date=%3C2021-04-22T12%3A18%3A00.000Z#graphs

However, the version 78 crash rate for this collection of signatures is very low https://crash-stats.mozilla.org/search/?release_channel=release&signature=~AsyncShutdownTimeout%20%7C%20profile-change-teardown%20%7C%20Extension%20shutdown&product=Thunderbird&date=%3E%3D2021-01-22T12%3A27%3A00.000Z&date=%3C2021-04-22T12%3A27%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

OTOH, it may help version 78 failures that fall under other crash signatures. (I'd feel better if we had direct feedback from version 78 users we know are crashing. bug 1667658 might be such a case.)

Comment 51

[Magnus Melin [:mkmelin]]

Comment on attachment 9206313 [details] [diff] [review]
1559448-esr78-v1.patch

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Should fix common crash
• User impact if declined: May crash
• Fix Landed on Version: 88
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): Ifdef Thunderbird so no risk for Firefox.
  It has worked fine on betas.
• String or UUID changes made by this patch: none

Comment 52

[Magnus Melin [:mkmelin]]

(Should also uplift bug 1694008.)

Comment 53

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9206313 [details] [diff] [review]
1559448-esr78-v1.patch

TB-only. Approved for 78.11esr.

Comment 54

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/04e1fdae7185

Comment 55

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9206313 [details] [diff] [review]
1559448-esr78-v1.patch

Clearing the esr78 approval flag to get this off the needs-uplift radar.