This happened to me on my work PC the other day and repro'ed on my home PC as well.

STR with 101.0b1 (and now updated for 104.0b2):

1. Go to Tools > Settings > Privacy & Security > Passwords > Saved Passwords
2. Highlight all of your saved passwords and click Remove All (assuming here that you know your password(s) and can re-enter them again later)
3. Close the Saved Logins windows. Close the Settings tab
4. File > Exit to shut down Thunderbird
5. Open Task Manager to verify that one instance of TB is still not yet shut down

Expected Result:

1. No hang that leads to an eventual crash

Actual Result:

1. Hang that leads to an eventual crash

Crash: https://crash-stats.mozilla.org/report/index/b73ae5d3-b38d-48fd-8286-9b14d0220507

Antony, does this crash for you on Mac?

TCW, how reproducible is this for you?

I was not able to reproduce on Mac nor Windows with 101.0b2 (but I would very much love to)

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

TCW, how reproducible is this for you?

I was not able to reproduce on Mac nor Windows with 101.0b2 (but I would very much love to)

Apparently not reproducible on 101.b2. I just tried and TB just repeatedly bombarded me with login window prompts a second after clearing out passwords. I didn't see that behavior in 101.0b1. So for now and as of 101.b2, seems it's WFM.

Odd though that that same thing I did on my office PC and home PC caused the shutdown crash. Are you able to at least verify that there are two crashes on the same day? Those would have been mine.

This was the crash that happened on my work PC: https://crash-stats.mozilla.org/report/index/b73ae5d3-b38d-48fd-8286-9b14d0220507 same as my home PC.

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

Antony, does this crash for you on Mac?

Not seen any evidence and I do edit and change PWs a few times...

Robert can you reproduce using the steps in comment 0 on Windows ?

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

Robert can you reproduce using the steps in comment 0 on Windows ?

Walt, can you reproduce a crash with steps in comment 0?

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

Robert can you reproduce using the steps in comment 0 on Windows ?

Hi, I cannot reproduce the crash on Windows 10 (64bit) using TB 91.11.0 (64-Bit)
and I cannot reproduce the crash using TB 102.0 (64-Bit) on Windows 10 (64bit)

No, I cannot reproduce using 91.11.0 on Fedora Linux.

I cannot reproduce the crash on Windows 10 (64 bit) using

• TB Daily 104.0a1 (2022-07-02) (64-bit)
• TB beta 103.0b2 (64-Bit)
  Best regards

Maybe bug 1629669 will help

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

Maybe bug 1629669 will help

Some similarities but not 100% 1:1. Could be caused by different things.

So I just tried to repro using 104.0b2 and my STR. I got this crash: https://crash-stats.mozilla.org/report/index/e0dca0f9-14f7-492e-b507-4e4e40220802

I am going to modify my STR a tad to reflect what I just did to repro.

I'm sure it probably won't make much difference but when I repro'ed the issue this time, it took TB a full 2m 45s from the time I did File > Exit until it disappeared from the screen. As before, one TB process was still running.

If I need to repro for you guys again, will I likely have any luck doing a perf profile? I'm guessing I will crash out before I can capture anything useful. But I can try if you want.

The STR didn't cause a crash for me on linux.

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

The STR didn't cause a crash for me on linux.

Can't be my profile since I started from complete scratch early in Feb this year. I just tried to repro and TB is sitting in a state waiting to crash. While it is doing so, I tried to grab a perf profile for 5 seconds. This is it: https://share.firefox.dev/3Shqwo1

And when I blew away all the passwords to repro, I had Error Console open but nothing showed up.

Once again I was able to easily repro. Here's the crash: https://crash-stats.mozilla.org/report/index/be460cf3-c7d2-450f-87b3-9a9530220803

Walt, can you reproduce this on Windows? And Linux?

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

Walt, can you reproduce this on Windows? And Linux?

I can not reproduce using Thunderbird 102.1.1 on Windows 10, or Fedora 35 Linux.

On Windows, I only had passwords for my POP3 account, and it's SMTP server.
Linux had those and passwords for my 4 IMAP accounts and my AIOE news account.

(In reply to WaltS48 [:walts48] from comment #19)

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

Walt, can you reproduce this on Windows? And Linux?

I can not reproduce using Thunderbird 102.1.1 on Windows 10, or Fedora 35 Linux.

On Windows, I only had passwords for my POP3 account, and it's SMTP server.
Linux had those and passwords for my 4 IMAP accounts and my AIOE news account.

So I am wondering how the heck I can repro with 100% ease and everyone else cannot. Could it be a setting I have turned on/off from the Settings menu? I'm curious if the fix in bug 1629669 will make it into 104.0b3 or b4? I can test again if it does.

This is how we look for 104.0b3: https://crash-stats.mozilla.org/report/index/b8f82bcb-876d-4398-9b27-05d510220810

Shows a slight signature change for 104.0b3. Only thing that changed between then and now is I am running 19045.1889 from yesterday's Patch Tuesday.

Well, I had high hopes for 104.0b4 but here is another crash I just repro'ed: https://crash-stats.mozilla.org/report/index/576cb0b4-b0da-4008-86e2-f2ac30220816

This is how we're looking for 105.0b1: https://crash-stats.mozilla.org/report/index/7ddc0d68-1b08-4731-82c0-57af60220825

Slight change between:
OLD: toolkit/xre/nsAppRunner.cpp:2060 > NEW: toolkit/xre/nsAppRunner.cpp:2069
OLD: mfbt/UniquePtr.h:275 > NEW: mfbt/UniquePtr.h:271
OLD: toolkit/xre/nsAppRunner.cpp:5914 > NEW: toolkit/xre/nsAppRunner.cpp:5940
OLD: toolkit/xre/nsAppRunner.cpp:5949 > NEW: toolkit/xre/nsAppRunner.cpp:5975
OLD: mail/app/nsMailApp.cpp:368 > NEW: mail/app/nsMailApp.cpp:389

So I am starting to suspect fully the password manager has some kind of bug because today something new happened. I woke my home PC from sleep and TB presented me with the username/password window as if it had forgotten them. Instead of entering the username and password and then proceeding to the "Allow TB to manage..." button, I simply closed the window using the [X] close button. I did a File > Exit action and TB went into a state of Not Responding to input. Task Manager showed it was still running but thinking about something. Eventually, it crashed: https://crash-stats.mozilla.org/report/index/9b3f9cac-4ab5-44c3-9060-9c9950220901

Signature is a bit different [@ shutdownhang | ZwWaitForAlertByThreadId | mozilla::TaskController::GetRunnableForMTTask | nsThread::Shutdown | nsThreadManager::ShutdownNonMainThreads ]

I am not able to reproduce this on Windows 10 using daily. But I am hopeful others can.

Can anyone else reproduce?

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

I am not able to reproduce this on Windows 10 using daily. But I am hopeful others can.

Can anyone else reproduce?

There's got to be something I have set on my instances of TB that allows me to repro with such ease.

This is how we're looking for 106.0b1: https://crash-stats.mozilla.org/report/index/41ba1bb4-6f87-4a48-adf4-21fd80220920

Signature has changed it seems: [@ shutdownhang | mozilla::OffTheBooksCondVar::Wait ]

Sadly I cannot add it to the bug title as it's now too long =\ Shall I open a new bug?

Bug 1790983 references this signature.

And this is with 106.0b5: https://crash-stats.mozilla.org/report/index/c0f48712-ffb1-4abe-987c-bf3990221011

Same @ shutdownhang | mozilla::OffTheBooksCondVar::Wait signature

This also looks like a duplicate of bug 1505660. The signature changes I'm doing in bug 1794587 will make the signatures in these bugs all the same.

The hang time, at least for me using my STR, has gotten progressively longer since 106. And with 107 it took around 4-5 minutes after a File > Exit action before TB finally crashed.

This is how we're looking for 107.0b1 build2: https://crash-stats.mozilla.org/report/index/09215680-e37b-454f-ba7d-165170221018
Still the same sig as in comment 26.

The only difference I see now is:

106.0b5
12 xul.dll XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) toolkit/xre/nsAppRunner.cpp:5934 cfi
13 xul.dll XRE_main(int, char**, mozilla::BootstrapConfig const&) toolkit/xre/nsAppRunner.cpp:5969 cfi

107.0b1
12 xul.dll XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) toolkit/xre/nsAppRunner.cpp:5937 cfi
13 xul.dll XRE_main(int, char**, mozilla::BootstrapConfig const&) toolkit/xre/nsAppRunner.cpp:5972 cfi

I got excited for a moment that this may have gotten fixed in 107.0b4 as I had removed two saved passwords (of four) from PW manager but it was a red herring. Took 4-5 minutes to eventually shut down and finally crash: https://crash-stats.mozilla.org/report/index/5184cdcd-5c31-4da9-800b-dee040221110

Signature seems a bit different though.

Yes, like bug 1790983, as of October 25 the signature will have changed. Thanks for checking it.

Just tested with the 108.0b1 build. Took around 4 minutes to crash but eventually did: https://crash-stats.mozilla.org/report/index/7af9cf9f-db02-4c4b-a145-6857f0221115

For me, I don't remember removing any saved passwords when my crash happened.

Just tested with the 109.0b1 build. Took around 4 minutes to crash but eventually did: https://crash-stats.mozilla.org/report/index/948e4027-ab0b-4c83-93a4-0ef770221214

Could you provide some info on the following queries:

If you restart Windows OS in 'Safe mode with Networking' and start Thunderbird as normal, then do usual remove password and exit test, do you stll get same problem hang/crash?

In the 'profile name' folder, how many 'prefs-n.js' files do you see ? (Where 'n' is a number)

If you put Thunderbird into 'Offline' mode first, then remove passwords and exit TB, do you get same result ?

(In reply to Anje from comment #37)

Could you provide some info on the following queries:

If you restart Windows OS in 'Safe mode with Networking' and start Thunderbird as normal, then do usual remove password and exit test, do you stll get same problem hang/crash?

Yes: https://crash-stats.mozilla.org/report/index/7a7bb16f-fb35-48f9-992c-28a780221215

In the 'profile name' folder, how many 'prefs-n.js' files do you see ? (Where 'n' is a number)

There's only one prefs.js file.

If you put Thunderbird into 'Offline' mode first, then remove passwords and exit TB, do you get same result ?

Nope. TB shuts down instantly. So what does that tell us?

This is how we look with 110.0b1: https://crash-stats.mozilla.org/report/index/7e8e87eb-ef29-4770-9160-3ad4b0230118

And though I doubt it would have any clues in it, I had error console running while in a state of TB being stuck shutting down and this is what it captured:

10:36:24.370 mailnews.smtp:
error { target: TCPSocket, isTrusted: true, name: "NetworkTimeoutError", message: "Network", errorCode: 2152398862, srcElement: TCPSocket, currentTarget: TCPSocket, eventPhase: 2, bubbles: false, cancelable: false, … }
SmtpClient.jsm:438:17
_onError resource:///modules/SmtpClient.jsm:438
goQuitApplication chrome://global/content/globalOverlay.js:96
oncommand chrome://messenger/content/messenger.xhtml:1

10:36:43.910
<Provider> does not support changing store on the fly. It is most likely that you see this error because you updated to Redux 2.x and React Redux 2.x which no longer hot reload reducers automatically. See https://github.com/reactjs/react-redux/releases/tag/v2.0.0 for the migration instructions. react-redux.js:881:13
Redux 3
React 13
goQuitApplication chrome://global/content/globalOverlay.js:96
oncommand chrome://messenger/content/messenger.xhtml:1

Worth noting that blocking Bug 1505660 is a topcrash for Thunderbird 102.6.1, ranking #2, and ranks #1 for 109.0b4.

shutdownhang | nsThread::Shutdown | nsThreadManager::ShutdownNonMainThreads
application

So here's another possible clue it might be password manager or OAuth2 related. Today was my last day of work and promptly at 5PM they killed my email account access. Upon arriving home and starting TB, it of course complained that it couldn't log in. The incessant password/OAuth2 prompt kept coming up until I was able to go to Account > Server Settings > and uncheck all options there as well as disabling my calendar.

Until I did so, I kept getting barraged with the incessant password/OAuth2 prompt that wasn't able to be dismissed. As such I crashed twice: https://crash-stats.mozilla.org/report/index/b75cb7cf-7338-4f26-83cb-f68bd0230208
https://crash-stats.mozilla.org/report/index/6fafbe50-b243-49ef-93a8-b66a10230208

(In reply to Arthur K. (he/him) from comment #42)

So here's another possible clue it might be password manager or OAuth2 related.

Very possible.

I just crashed nightly bp-900ad218-a365-4f1b-b64a-2724e0230707 during a short startup that was needed to get an update. And password prompts were happening.

For 115.0, this is #1 crash. For example Bp-4a193911-3e27-4bd5-8f07-a8b360230714

Gecko thread is going to shut down. But IMAP thread doesn't finish since OAuth2's monitor isn't signal.

• nsImapProtocol::AuthLogin should return error immediately if shutdown phase is AppShutdown or something.
• Use RunOnShutdown or shutdown observer to signal OAuth2's monitor.
• (optional) GetXOAuth2String and SupportsOAuth2 should check return value of NS_DispatchToMainThread. It can return error. If error, this lock occurs.

This is activity after removing all saved PWs: https://share.firefox.dev/458JLWb
(In reply to Wayne Mery (:wsmwk) from comment #43)

(In reply to Arthur K. (he/him) from comment #42)

So here's another possible clue it might be password manager or OAuth2 related.

Very possible.

I just crashed nightly bp-900ad218-a365-4f1b-b64a-2724e0230707 during a short startup that was needed to get an update. And password prompts were happening.

I tested this with 115.1.0 RC and it still crashed but took well close to 5 minutes before crash handler showed up: https://crash-stats.mozilla.org/report/index/a42f3508-e568-4764-bf68-49a600230730

Here's hoping bug 1788599 will help out here. If we do spin a 115.1.1 with bug 1788599 in it, I'll try and remember to come back here and test again.

(In reply to Arthur K. (he/him) from comment #46)

Here's hoping bug 1788599 will help out here. If we do spin a 115.1.1 with bug 1788599 in it, I'll try and remember to come back here and test again.

1788599 may help with the amount of time. But I would not expect it to help with the crash.

Arthur, do you use a smartcard?

(I wonder if Thunderbird has a third party pkcs#11 module loaded, which might not release some resources on shutdown, this idea is just a shot in the wild.)

(In reply to Kai Engert (:KaiE:) from comment #48)

Arthur, do you use a smartcard?

I do not.