1788599 - Shutdown hang in nsMsgAccountManager::CleanupOnExit, if IMAP account is configured to cleanup/expunge on exit

Status: RESOLVED FIXED

(Thunderbird :: General, defect, P2)

Description

Both Thunderbird 105.0b1 and 105.0b2 have delayed shutdown in Arch Linux compared to earlier versions. When started from the console, there is a console message when Thunderbird shuts down:

[Parent 3138, Main Thread] WARNING: ContentParent: id=7f94cd9ea400 - BlockShutdown: NotifyImpendingShutdown.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:3626

This looks connected to the similar bug referencing recent Firefox builds at bug 1783512

Comment 1

[Jens Stutte [:jstutte]]

(In reply to Mike Cloaked from comment #0)

Both Thunderbird 105.0b1 and 105.0b2 have delayed shutdown in Arch Linux compared to earlier versions.

Which versions do you compare here?

When started from the console, there is a console message when Thunderbird shuts down:

[Parent 3138, Main Thread] WARNING: ContentParent: id=7f94cd9ea400 - BlockShutdown: NotifyImpendingShutdown.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:3626

This looks connected to the similar bug referencing recent Firefox builds at bug 1783512

This is just a message that helps us investigating shutdown hangs and is not concerning as such.

Can you provide more information to make this actionable? Thank you for your support

Comment 2

[Mike Cloaked]

I have been using Thunderbird beta for some years, and for recent 104.0bx beta series the shutdown takes a few seconds before the UI closes. For 105.0b1 and 105.0b2 it is perhaps 8 or 9 seconds, and although it does shut down, the additional time is rather frustrating when you are used to only 2 to 3 seconds (at least on the machines I have it running on). Are you suggesting that increase in shutdown time is to be accepted, for normal use, so that there is more information during shutdown hangs, but in normal use, the additional delay will remain, but presumably then be removed when thunderbird moves from beta to the next release? Or is there a way to turn off the additional processing involved (perhaps via a parameter change in the config editor)?

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Moving Thunderbird shutdown regression to Thunderbird for analysis by the Thunderbird team. As :jstutte indicates, the message is just indicating that a content process was told that shutdown is happening; if the content process (or parent process) fails to shutdown, that's because of Thunderbird application logic (or content logic under its control) doing something and not stopping doing it in a timely fashion.

In order to make this actionable for the Thunderbird team, you'll probably want to gather a profile as documented at https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance which can help show what logic is running. Note that shutdown profiles are a special-case, and there's a link at the bottom of the document to more details on that.

Once the Thunderbird team has identified what's running that should not still be running, they'll probably want to add an async shutdown blocker which can receive a BlockShutdown call itself and cause things to abort.

Comment 4

[Mike Cloaked]

I have tried getting a performance profile to capture diagnostic information when thunderbird shuts down, but so far I have been unable to capture a file with the data. It does shut down, but interestingly shuts down quite fast with the performance profile set to 'start recording' , compared to when that is not set up (!), but no file seems to have been saved. I will go through the links again and try again later when I get some time.

Comment 5

[Mike Cloaked]

OK I set the additional environment variables for the profile at startup from the command line and have captured a profile file. The console contained the following lines from the point thunderbird 105 started, to when it was shut down ( I will attach the performance profile file shortly):

/usr/lib/libicudata.so.71: unable to generate file identifier
/usr/lib/libicudata.so.71: unable to generate file identifier
/usr/lib/libicudata.so.71: unable to generate file identifier
[Parent 3700, Main Thread] WARNING: ContentParent: id=7f01fe966d00 - BlockShutdown: NotifyImpendingShutdown.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:3626
[Parent 3700, Main Thread] WARNING: ContentParent: id=7f01ef1ae100 - BlockShutdown: NotifyImpendingShutdown.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:3626
[Parent 3700, Main Thread] WARNING: ContentParent: id=7f01fe966d00 - BlockShutdown: CanSend.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:3671
[Parent 3700, Main Thread] WARNING: ContentParent: id=7f01fe966d00 - ShutDownProcess: Shutdown already pending.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:1824
[Parent 3700, Main Thread] WARNING: ContentParent: id=7f01ef1ae100 - BlockShutdown: CanSend.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:3671
[Parent 3700, Main Thread] WARNING: ContentParent: id=7f01ef1ae100 - ShutDownProcess: Shutdown already pending.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:1824
[Parent 3700, Main Thread] WARNING: ContentParent: id=7f01fe966d00 - ShutDownProcess: Closing channel.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:1843
[Parent 3700, Main Thread] WARNING: ContentParent: id=7f01fe966d00 - RemoveShutdownBlockers: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:3786
[Parent 3700, Main Thread] WARNING: ContentParent: id=7f01ef1ae100 - ShutDownProcess: Closing channel.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:1843
[Parent 3700, Main Thread] WARNING: ContentParent: id=7f01ef1ae100 - RemoveShutdownBlockers: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:3786

Comment 6

[Mike Cloaked]

The file is slightly over the 10MB limit so I will have to upload it to a pastebin. Also the shutdown during the performance profile capture was about the same as previously around 8 seconds.

Comment 7

[Mike Cloaked]

The performance profile for the shutdown is at http://0x0.st/op0i.json

Comment 8

[Mike Cloaked]

With 105.0b3 the WARNING line on the console output when quitting Thunderbird, concerning the "BlockShutdown: NotifyImpendingShutdown" is no longer present, but Thunderbird shutdown now takes about 15 seconds instead of 8 or 9 seconds in the previous version!

Comment 9

[Mike Cloaked]

No change with 105.0b4

Comment 10

[Richard Leger]

(In reply to Mike Cloaked from comment #7)

The performance profile for the shutdown is at http://0x0.st/op0i.json

Hi Mike,

As a suggestion, you msay be able to load the profile you gathered into https://profiler.firefox.com the use the upload button to save it and share the permalink generated here.

Fyi https://profiler.firefox.com/docs/#/./guide-getting-started

This way the profile is readable and accessible to anyone reading this bug report.

Regards,

Comment 11

[Mike Cloaked]

Here it is: https://share.firefox.dev/3RQZpzA

Comment 12

[Richard Leger]

(In reply to Mike Cloaked from comment #11)

Here it is: https://share.firefox.dev/3RQZpzA

Just to confirm, as suggested by Andrew in Comment 3, you used the MOZ_PROFILER_SHUTDOWN=<filename> option (source:https://profiler.firefox.com/docs/#/./guide-startup-shutdown?id=shutdown) to generate that profile, right?

Comment 13

[Mike Cloaked]

Correct. as per the link you quoted.

Comment 14

[Mike Cloaked]

The 15 seconds shutdown time remains the case with 106.0b1 where the console message is back:

[Parent 1570, Main Thread] WARNING: ContentParent: id=7fa0638e7c00 - BlockShutdown: NotifyImpendingShutdown.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:3635

Comment 15

[Richard Leger]

Hi Mike,

How do you shutdown TB? Via Hamburger menu > Exit or via the main windows close icon?
Does it makes a difference if you use either or?

Does TB stop shunting down (process still running) or the running process do shutdown in the end but just a delay appears and TB close too slowly?

Could you also try to start TB in Safe Mode (Hamburger menu > Help > Troubleshoot Mode, tick Disable All add-ons and continue in Troubleshoot mode), wait for a bit, use TB as normal then shutdown TB, does the shutdown issue still happens then?

What accounts and features do you currently have enabled in TB?

Have you tried in a clean new empty profile? Issue still occurs? Error console message still appear in that case?

Regards,

Comment 16

[Jens Stutte [:jstutte]]

(In reply to Mike Cloaked from comment #14)

The 15 seconds shutdown time remains the case with 106.0b1 where the console message is back:

From the profile it seems Thunderbird is stuck inside nsMsgAccountManager::CleanupOnExit, in particular inside some of the PR_Wait calls I see there. It might look as if the root monitor is blocked for quite a while?

Edit: Actually while (inProgress && loopCount++ < 5000) might even suggest that root is never unblocked but we give just up (numerically 5000*1000 usec would add up to a 5 sec delay only, but I can imagine that the processing in between easily doubles this). Besides investigating what blocks root, this could benefit also from a SpinEventLoopUntil and an appropriate timeout, to make the timings more reliable.

[Parent 1570, Main Thread] WARNING: ContentParent: id=7fa0638e7c00 - BlockShutdown: NotifyImpendingShutdown.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:3635

Again, these are harmless (but too verbose) messages that help us just in debugging, so their existence is normal every single time we shut down a content process.

Comment 17

[Wayne Mery (:wsmwk)]

Mike, can you find the regression range using https://mozilla.github.io/mozregression/ ?

Comment 18

[Mike Cloaked]

I am afraid I don't have enough time to run bisection analysis. I get the same 15 or so second shutdown time whether I close going to File-Quit, or whether I click the close 'cross' at the top right of the window - the difference between the two is that from the File menu, nothing looks changed until the window closes about 15 seconds later - if I close using the 'x' at the top right of the Thunderbird window the list of mails in the main pane clears away, and the rest of the window and menu items remains visible until it all disappears around the 15 second mark after clicking the 'x'. As to what accounts and features are set up - two gmail accounts (imap), and one local imap, plus one google calendar which is not supported by the Provider for Google calendar extension for Thunderbird 104 and later - it shows as being disabled - the calendar initially loads but then becomes disabled. The extension shows it is in a disabled state. I also use the sequoia librnp which has been working fine.

Comment 19

[Mike Cloaked]

Thunderbird 106.0b2 takes even longer to shut down.  The UI closes after about 15 seconds running in Arch Linux, but the process continues for a long period before the console final shows it has closed down, with the console messages showing: [Parent 4874, Main Thread] WARNING: ContentParent: id=7f5497b9f000 - BlockShutdown: NotifyImpendingShutdown.: file /builds/worker/checkouts/gecko/dom/ipc/ContentParent.cpp:3635
RunWatchdog: Mainthread nested event loops during hang:
--- storage::Service::Observe(xpcom-shutdown-threads)
ExceptionHandler::GenerateDump cloned child 5215
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child

Comment 20

[Mike Cloaked]

After closing Thunderbird 106.0b2 as above, and restarting, allowing time to sync, and then closing down, there was still the 15 second delay before the UI closed, but no long further delay to when all related processes closed. Further confirmation of whether this is now the norm for further shutdowns will be checked.

Comment 21

[Jens Stutte [:jstutte]]

(In reply to Jens Stutte [:jstutte] from comment #16)

Again, these are harmless (but too verbose) messages that help us just in debugging, so their existence is normal every single time we shut down a content process.

FWIW, I filed bug 1793904 in order to reduce the log level.

Comment 22

[Mike Cloaked]

I have now been testing 106.0b5 on my own profile as well as my wife's profile - on my profile the 15 second shutdown time is still there, but on my wife's profile shutdown is almost immediate once the 'quit' command is initiated. The primary difference is that my main inbox has around 50k messages, whereas my wife's profile has a small fraction of that number of messages - so it looks like the large number of emails may be the reason behind the long shutdown time. I will at some point go through older messages and delete a significant number, and see if that reduces the shutdown time. If that is the case I wonder if there is a lot of processing required when dealing with accounts with large numbers of messages in recent versions compared to <105 - since prior to version 105.0bX shutdown time was short despite having large numbers of messages in the same account?

Comment 23

[Mike Cloaked]

After deleting around a third of all email in my account, and compacting folders, as well as running a repair to re-download all the mail, the total storage was only reduced from 12GB to 11GB, and shutdown still takes about 15 seconds! So something changed between 104.0b4 and later versions that led to a significant delay in shutdown - with the same account on another Arch linux machine, with the same profile, but running 104.0b4, that version continues to shut down in a second or two at most.

Comment 24

[jan.t.neurer]

@Mike Cloaked: Can you check, if going into offline mode before quitting reduces shutdown time?

I'm seeing very similar issues: bug 1793437

Comment 25

[Wayne Mery (:wsmwk)]

Please use bug #### when referencing bug reports, so that bugzilla can helpfully provide bug information.

Comment 26

[Mike Cloaked]

@jan.t.neurer: Yes if I switch to 'work offline' then Thunderbird beta 108.0b2 closes almost instantly. If I restart Thunderbird and let it sync and close down without going into offline mode, then it again takes around 15 seconds to shut down. So yes I am seeing the same behaviour.

Comment 27

[Wayne Mery (:wsmwk)]

Mike's performance profile shows waiting on nsMsgAccountManager::CleanupOnExit.

Do you have "empty trash on exit" enabled ? Then you are looking at bug 1704637.
Or do you have "Clean up ("Expunge") Inbox on exit" enabled?

Comment 28

[Mike Cloaked]

I just checked - I have under Server settings -> Message storage "Clean up ("Expunge") Inbox on Exit" checked (i.e. enabled). Just below that under the server settings I have no check in the box for "Empty Deleted folder on Exit" - However in the recent betas I don't see the setting you quote as "empty trash on exit" which is quoted in the bug report referenced.

Comment 30

[Wayne Mery (:wsmwk)]

Mozregression puts the range at 2022-08-05 is good, 2022-08-06 is bad, and indicates this is a regression of Bug 1654006 - Add onAfterSend event to compose API.
However, also in that range is Bug 1769152 - Make IOUtils Shutdown blockers depend on previous phase completion r=nika

Note, version 102 works fine for me. But bug 1704637 is clearly an issue for some users on version 102.

Lastly, is Bug 1843744 another victim? Crash in [@ mozilla::dom::workerinternals::RuntimeService::CrashIfHanging] shutting down Thunderbird (exit/quit)

Comment 31

[Wayne Mery (:wsmwk)]

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

Mozregression puts the range at 2022-08-05 is good, 2022-08-06 is bad, and indicates this is a regression of Bug 1654006 - Add onAfterSend event to compose API.
However, also in that range is Bug 1769152 - Make IOUtils Shutdown blockers depend on previous phase completion r=nika

Note, version 102 works fine for me. But bug 1704637 is clearly an issue for some users on version 102.

Lastly, is Bug 1843744 another victim? Crash in [@ mozilla::dom::workerinternals::RuntimeService::CrashIfHanging] shutting down Thunderbird (exit/quit)

And in fact, on Mac I just crashed on shutdown bp-fb2bc3c5-300d-4ee1-bc87-b5ebc0230718 because I had one pop account set to empty trash on exit.

Comment 32

[Landry Breuil (:gaston)]

fwiw seeing the same symptoms with 115.0.1 on OpenBSD, exiting is super slow, but i don't see a crash - there's no crash reporter on OpenBSD, but i dont get a coredump either.

going offline or toggling back mail.server.server1.cleanup_inbox_on_exit to false definitely allows thunderbird to exit straight away.

bug #1841597 might be a duplicate of this one ?

Comment 34

[Kai Engert (:KaiE:)]

I can reproduce. For every configured IMAP server that has cleanup_inbox_on_exit set to true, we get 5-6 seconds delay on exit. So for 3 accounts configured, I see an >18 seconds delay.

nsMsgAccountManager::CleanupOnExit() has a loop that processes each account separately, one after the other. And there's a timeout guard in that code, it will stop processing for an account after 5 seconds.

I'm investigating what's going on.

Comment 35

[Kai Engert (:KaiE:)]

In order to stop/leave when done, it's necessary that GetCleanupInboxInProgress returns false.
That requires that m_cleanupInboxInProgress is set to false, which is done when nsMsgAccountManager::OnStopRunningUrl is reached with an URL.

Apparently nsMsgAccountManager::OnStopRunningUrl isn't reached with the necessary URL.

I wonder if that's a regression from bug 1782374.
https://hg.mozilla.org/comm-central/rev/392004364d88

Maybe that'e because nsImapMailFolder::ExpungeAndCompact no longer sets m_urlListener ?
I don't yet understand if the assignment to m_urlListener was removed deliberately.

Comment 36

[Kai Engert (:KaiE:)]

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

Maybe that's because nsImapMailFolder::ExpungeAndCompact no longer sets m_urlListener ?

I tried, doesn't help to revert that.

We need to find out why OnStopRunningUrl no longer provides an URL parameter.

I have a hack that apparently fixes it, but I want to discuss it with BenC, will do that in phabricator.

Comment 37

[Kai Engert (:KaiE:)]

Attachment: Bug 1788599 - ExpungeAndCompact must provide url parameter to OnStopRunningUrl to allow immediate exit. r=BenC

Comment 38

[Kai Engert (:KaiE:)]

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

Lastly, is Bug 1843744 another victim? Crash in [@ mozilla::dom::workerinternals::RuntimeService::CrashIfHanging] shutting down Thunderbird (exit/quit)

It's possible.

If a user has several accounts, and several of them are configured with cleanup_inbox_on_exit=true, it could hang for a very long time.
(Number of accounts, multiplied by 5 seconds.)

Comment 39

[Ben Campbell]

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

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

Maybe that's because nsImapMailFolder::ExpungeAndCompact no longer sets m_urlListener ?

I tried, doesn't help to revert that.

We need to find out why OnStopRunningUrl no longer provides an URL parameter.

The reason is that there is no URL associated with compacting folders.
The nsUrlListener was only ever used as a "I'm done!" notification (the code never even called onStartRunningUrl(), only onStopRunningUrl()).
When I overhauled the compaction code, I left that as is (I probably should have changed it to a less confusing mechanism!)

However, for IMAP, the compact() is really an EXPUNGE operation, followed by a compaction. The expunge operation does have a URL, and this what nsMsgAccountManager::OnStopRunningUrl() is waiting for.
But after my compaction changes, that URL is never sent to nsMsgAccountManager::OnStopRunningUrl() (it wouldn't make any sense to do that - that OnStopRunningUrl() is to be notified when both the expunge and the compact are completed. I'd guess the old code did the Expunge, then left the compaction operation running shudder).

So... as a result, nsMsgAccountManager::OnStopRunningUrl() never sees that the expunge+compaction has completed, and as a result falls into the sketchy 5 second timeout check, which I think is where we're seeing the problem.

The correct solution is for nsMsgAccountManager() to pass in a better listener callback to compact(), track when all the folders have finished (or when a 5 second timeout elapses), then continue cleanup.

The old compaction system "worked", but It looks like it was just waiting for the first expunge to complete. This means that all the subfolders could still be expunging, and mbox compaction could still be running when the cleanup continues. That seems like it could have lead to some astoundingly bad behaviour :-)

I have a hack that apparently fixes it, but I want to discuss it with BenC, will do that in phabricator.

I think the hack essentially restores the old behaviour, but it notifies compaction operations finishing immediately, even if they're still running, which was they whole thing I was trying to fix with my previous compaction changes.

I'm going to try another approach.

Comment 40

[Kai Engert (:KaiE:)]

Thanks Ben for the explanation, I'm glad you understand that code and that you have an idea for an alternative fix!

Comment 41

[Ben Campbell]

(In reply to Ben Campbell from comment #39)

The old compaction system "worked", but It looks like it was just waiting for the first expunge to complete. This means that all the subfolders could still be expunging, and mbox compaction could still be running when the cleanup continues. That seems like it could have lead to some astoundingly bad behaviour :-)

I'll walk that back - it loops through all the subfolders, but only to find the inbox. It only kicks off compact/expunge for the inbox, so not so bad. It was still waiting only for the expunge, but in practical terms folder compaction complete waaaay before the network traffic round-trip, so it was probably fine 99.9999% of the time.

Comment 42

[Ben Campbell]

Seems there's an easy fix: it turns out that nsMsgAccountManager::OnStopRunningUrl() is only ever used to notify the completion of the compaction (null url) and the trash emptying (a deleteAllMessages IMAP url).
So it'd be fine to just check for a null url there instead of the IMAP expunge url, to detect the completion of compaction.

However, it irks me that nsMsgAccountManager inherits from nsIUrlListener just for this purpose, so I'm preparing a patch to remove that inheritance while I'm at it.

If you want a simpler patch to land immediately, you might prefer to just have the null-url check in nsMsgAccountManager::OnStopRunningUrl() instead... I can upload a new patch for that if you like, but probably quicker for you to do it yourself!

Comment 43

[Ben Campbell]

Attachment: Bug 1788599 - Fix always-wait-until-5sec-timeout bug when expunge-inbox-upon-exit setting is used. r=kaie

nsMsgAccountManager::OnStopRunningUrl() was waiting for an IMAP Expunge url
that would never arrive. Previous work on compaction/expunging meant that a
nullptr url would be sent when the expunge+compact combo was completed.

This patch also ditches the nsIUrlListener inheritance and moves the
completion-handling code closer to where the expunge/compact is started.

Comment 44

[Ben Campbell]

For testing/replication of the bug, you need to have expunge-upon-exit set, and you may as well also set empty-trash-upon-exit too.

In 'Account Settings'/'Server Settings':
Under the 'Message Storage' heading:

• 'Clean up ("Expunge") Inbox on Exit'
• 'Empty Trash on Exit' checkboxes.

(or non-English equivalents :-)

Comment 48

[Kai Engert (:KaiE:)]

Thanks Ben, great work, I'm very glad that you know this code well!

Comment 49

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d389edc8f7b1
Fix always-wait-until-5sec-timeout bug when expunge-inbox-upon-exit setting is used. r=kaie

Comment 50

[Kai Engert (:KaiE:)]

Comment on attachment 9346168 [details]
Bug 1788599 - Fix always-wait-until-5sec-timeout bug when expunge-inbox-upon-exit setting is used. r=kaie

[Approval Request Comment]
Regression caused by (bug #): 1782374
User impact if declined: ugly, very long on exit, even crashing, delaying OS shutdown
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky): seems low risk

Comment 51

[Kai Engert (:KaiE:)]

Comment on attachment 9346168 [details]
Bug 1788599 - Fix always-wait-until-5sec-timeout bug when expunge-inbox-upon-exit setting is used. r=kaie

While the patch seems safe, a bit of baking in c-c and beta would be good.

Comment 52

[Wayne Mery (:wsmwk)]

Comment on attachment 9346168 [details]
Bug 1788599 - Fix always-wait-until-5sec-timeout bug when expunge-inbox-upon-exit setting is used. r=kaie

This will be on beta after Monday's merge, so no uplift required.
Though it still needs to land on c-c.

Thanks everyone for pushing this through.

Comment 53

[Wayne Mery (:wsmwk)]

While the patch seems safe, a bit of baking in c-c and beta would be good.

If it's on daily by Monday so I can test it, and if there is wider opinions that it is likely safe, then perhaps we respin 115.1.0. Otherwise,
the conservative approach is a good default and we wait for 115.1.1

Comment 54

[Arthur K. (he/him)]

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

While the patch seems safe, a bit of baking in c-c and beta would be good.

If it's on daily by Monday so I can test it, and if there is wider opinions that it is likely safe, then perhaps we respin 115.1.0. Otherwise,
the conservative approach is a good default and we wait for 115.1.1

I see no reason to rush this or respin. Safer to let is bake it even if it's a trivial fix. Someone once said something about the road to h*ll being paved with trivial fixes.

Comment 55

[Arthur K. (he/him)]

Does anyone know for sure if fixing this has a knock-on effect for bug 1768344 or no relation here?

Comment 56

[Wayne Mery (:wsmwk)]

Though it still needs to land on c-c.

I see it's already landed. I also see that a build was triggered yesterday. So I see ...

In multiple restarts of Version 117.0a1 Build ID 20230729220048 there are no shutdown delays, and so far no side effects.

Anyone else seeing side effects?

Comment 57

[Wayne Mery (:wsmwk)]

Comment on attachment 9346168 [details]
Bug 1788599 - Fix always-wait-until-5sec-timeout bug when expunge-inbox-upon-exit setting is used. r=kaie

[Triage Comment]
Approved for esr115.

Discussed on IRC. It potentially hides other bugs. And only impact shutdown, so how much damage could it do? So I'm inclined to take it, even though it hasn't yet passed beta.

Comment 58

[Rob Lemley [:rjl]]

Thunderbird 115.1.0:
https://hg.mozilla.org/releases/comm-esr115/rev/bbb351cd8954

Comment 59

[Wayne Mery (:wsmwk)]

However, this patch does not appear to have helped bug 1843744 comment 5

Comment 60

[Arthur K. (he/him)]

(In reply to Mike Cloaked from comment #4)

I have tried getting a performance profile to capture diagnostic information when thunderbird shuts down, but so far I have been unable to capture a file with the data. It does shut down, but interestingly shuts down quite fast with the performance profile set to 'start recording' , compared to when that is not set up (!), but no file seems to have been saved. I will go through the links again and try again later when I get some time.

This "shuts down quite fast with the performance profile set to 'start recording'" is something I too saw when trying to capture a perf profile recently in bug 1704637 comment 18

Comment 61

[Mike Cloaked]

Although I haven't tried to get performance profiles recently, with recent beta 117.0b3 currently as well as the previous few betas Thunderbird on my systems now shuts down significantly faster than earlier versions. One of my systems has Thunderbird shut in a couple of seconds, and the slowest in about 8 seconds. It does seem that once Thunderbird is running time needs to be allowed for the initial sync before attempting to close down again, or the shutdown does take longer. But a significant improvement compared to versions from a year or so back.