1508649 - Thunderbird Crash sending mail in shutdownhang | _PR_MD_WAIT_CV | _PR_WaitCondVar | PR_Wait | PR_CWait | nsMsgCopy::DoCopy - Error saving to Sent folder

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Wayne Mery (:wsmwk)]

Attachment: nsMsgCopy-DoCopy graph.png

#74 crash for 52.9.1, #40 for 60.3.0. TBD for 60.3.1.
An odd dip in crash rate mid-august through Sept, seen in attached graph.

In beta, the signature seems to have changed to shutdownhang | _PR_MD_WAIT_CV | PR_Wait | PR_CWait | nsMsgCopy::DoCopy

We don't have a testcase but comments say sent message not being saved to Sent folder.

bp-39409cdf-a0e5-49e8-b35f-0b6bc0181119.  60.3.1  no significant add-ons
=============================================================
Top 10 frames of crashing thread:

0 ntdll.dll NtWaitForSingleObject 
1 kernelbase.dll WaitForSingleObjectEx 
2 kernelbase.dll WaitForSingleObject 
3 nss3.dll _PR_MD_WAIT_CV nsprpub/pr/src/md/windows/w95cv.c:248
4 nss3.dll _PR_WaitCondVar nsprpub/pr/src/threads/combined/prucv.c:172
5 nss3.dll PR_WaitCondVar nsprpub/pr/src/threads/combined/prucv.c:525
6 nss3.dll PR_Wait nsprpub/pr/src/threads/prmon.c:294
7 nss3.dll PR_CWait nsprpub/pr/src/threads/prcmon.c:394
8 xul.dll nsMsgCopy::DoCopy comm/mailnews/compose/src/nsMsgCopy.cpp:284
9 xul.dll nsMsgCopy::StartCopyOperation comm/mailnews/compose/src/nsMsgCopy.cpp:226
10 xul.dll nsMsgComposeAndSend::StartMessageCopyOperation comm/mailnews/compose/src/nsMsgSend.cpp:4826
11 xul.dll nsMsgComposeAndSend::MimeDoFCC comm/mailnews/compose/src/nsMsgSend.cpp:4795
12 xul.dll nsMsgComposeAndSend::SendToMagicFolder comm/mailnews/compose/src/nsMsgSend.cpp:4244
13 xul.dll nsMsgComposeAndSend::DeliverMessage  comm/mailnews/compose/src/nsMsgSend.cpp:3203
14 xul.dll nsMsgComposeAndSend::GatherMimeAttachments	comm/mailnews/compose/src/nsMsgSend.cpp:994
=============================================================

bp-d259c4ca-cdd8-4131-82bc-f75d50181006  60.0b11

Comment 1

[Wayne Mery (:wsmwk)]

In the right hand side of that graph we see in mid-November the beginnings of a significant decrease for shutdownhang | _PR_MD_WAIT_CV | _PR_WaitCondVar | PR_Wait | PR_CWait | nsMsgCopy::DoCopy  which in fact has persisted.  The crash rate for v60 appears to be about 1/6 the rate of v52.

Comment 2

[Wayne Mery (:wsmwk)]

Became a solid topcrash in the vicinity of 60.5.0. So 60.5.0 introduces some regressive behavior. https://www.thunderbird.net/en-US/thunderbird/60.5.0/releasenotes/

Attachment related?

A common crash comment "Thunderbird can send, but not copy to SEND folder." bp-7bd0cfae-242b-48ef-a5f4-105f40190208

0 ntdll.dll NtWaitForSingleObject context
1 kernelbase.dll WaitForSingleObjectEx cfi
2 kernelbase.dll WaitForSingleObject cfi
3 nss3.dll _PR_MD_WAIT_CV nsprpub/pr/src/md/windows/w95cv.c:248 cfi
4 nss3.dll _PR_WaitCondVar nsprpub/pr/src/threads/combined/prucv.c:172 cfi
5 nss3.dll PR_WaitCondVar nsprpub/pr/src/threads/combined/prucv.c:525 cfi
6 nss3.dll PR_Wait nsprpub/pr/src/threads/prmon.c:294 cfi
7 nss3.dll PR_CWait nsprpub/pr/src/threads/prcmon.c:394 cfi
8 xul.dll nsMsgCopy::DoCopy(nsIFile*, nsIMsgFolder*, nsIMsgDBHdr*, bool, nsIMsgWindow*, nsIMsgSend*) comm/mailnews/compose/src/nsMsgCopy.cpp:284 cfi
9 xul.dll nsMsgCopy::StartCopyOperation(nsIMsgIdentity*, nsIFile*, int, nsIMsgSend*, char const*, nsIMsgDBHdr*) comm/mailnews/compose/src/nsMsgCopy.cpp:226 cfi
10 xul.dll nsMsgComposeAndSend::StartMessageCopyOperation(nsIFile*, int, nsTString<char> const&) comm/mailnews/compose/src/nsMsgSend.cpp:4815 cfi
11 xul.dll nsMsgComposeAndSend::MimeDoFCC(nsIFile*, int, char const*, char const*, char const*) comm/mailnews/compose/src/nsMsgSend.cpp:4784 cfi
12 xul.dll nsMsgComposeAndSend::SendToMagicFolder(int) comm/mailnews/compose/src/nsMsgSend.cpp:4233 cfi
13 xul.dll nsMsgComposeAndSend::DeliverMessage() comm/mailnews/compose/src/nsMsgSend.cpp:3192 cfi
14 xul.dll nsMsgComposeAndSend::GatherMimeAttachments() comm/mailnews/compose/src/nsMsgSend.cpp:994 cfi
15 xul.dll nsMsgComposeAndSend::HackAttachments(nsIArray*, nsIArray*) comm/mailnews/compose/src/nsMsgSend.cpp:2533 cfi
16 xul.dll nsMsgComposeAndSend::Init(nsIMsgIdentity*, char const*, nsMsgCompFields*, nsIFile*, bool, bool, int, nsIMsgDBHdr*, char const*, nsTSubstring<char> const&, nsIArray*, nsIArray*, nsTSubstring<char16_t> const&, nsTSubstring<char> const&, int) comm/mailnews/compose/src/nsMsgSend.cpp:3115 cfi
17 xul.dll nsMsgComposeAndSend::CreateAndSendMessage(nsIEditor*, nsIMsgIdentity*, char const*, nsIMsgCompFields*, bool, bool, int, nsIMsgDBHdr*, char const*, nsTSubstring<char> const&, nsIArray*, nsIArray*, mozIDOMWindowProxy*, nsIMsgProgress*, nsIMsgSendListener*, nsTSubstring<char16_t> const&, nsTSubstring<char> const&, int) comm/mailnews/compose/src/nsMsgSend.cpp:4118 cfi
18 xul.dll nsMsgCompose::SendMsgToServer(int, nsIMsgIdentity*, char const*) comm/mailnews/compose/src/nsMsgCompose.cpp:1267 cfi
19 xul.dll nsMsgCompose::SendMsg(int, nsIMsgIdentity*, char const*, nsIMsgWindow*, nsIMsgProgress*) comm/mailnews/compose/src/nsMsgCompose.cpp:1486 cfi
20 xul.dll NS_InvokeByIndex xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_msvc.asm:54 cfi

Comment 3

[Wayne Mery (:wsmwk)]

Continuing comment 0:
a) I haven't done a full numerical analysis so this is mostly eyeball and
b) update rate for various v60.x increased over time (Sept-Jan), so reading the tea leaves and the conclusion might be wrong that some newer version has a regression.

Unfortunately the crash rate or non-release builds is very low, so we lack data => and so can't determine whether or when things got worse https://crash-stats.mozilla.com/search/?signature=%3Dshutdownhang%20%7C%20_PR_MD_WAIT_CV%20%7C%20_PR_WaitCondVar%20%7C%20PR_Wait%20%7C%20PR_CWait%20%7C%20nsMsgCopy%3A%3ADoCopy&release_channel=%21release&product=Thunderbird&date=%3E%3D2018-10-18T11%3A40%3A00.000Z&date=%3C2019-01-18T11%3A40%3A00.000Z&_facets=signature&_facets=build_id&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-build_id

Therefore another possible conclusion is the code went bad in the 60.0b* cycle, and the topcrash emerged only when we significantly increased the v60 update rate. (I'm not totally sold on this idea)

6.5.2 bp-2c6378aa-bf95-4ecb-8203-9b1410190317 Thunderbird claimed an email was sent but not saved to the Sent Folder giving me the options to Retry/Save/Not Save. I selected Save but could not verify the mail had been saved. I checked for Update and founs that an Update was claimed to be be running

52.9.1 bp-b609baa5-f127-452d-a9a7-04b830181206 1.Thunderbird won't save emails as always. 2. I'm getting no new emails since yesterday at Oh!Emails just arrived and the 'waiting for something' circling signal is gone! Hurrah
52.9.1 bp-46f6bc91-9be7-40e1-8a71-9b86b0181102 Unable to send emails - states outgoing server(SMPT) smpt.gmail is unknown. Server may be incorrectly configured. verify outgoing sever settings are correct and try again. Don't understand any of this

https://crash-stats.mozilla.com/search/?signature=%3Dshutdownhang%20%7C%20_PR_MD_WAIT_CV%20%7C%20_PR_WaitCondVar%20%7C%20PR_Wait%20%7C%20PR_CWait%20%7C%20nsMsgCopy%3A%3ADoCopy&product=Thunderbird&date=%3E%3D2018-09-18T10%3A53%3A00.000Z&date=%3C2019-01-31T10%3A53%3A00.000Z&_facets=signature&_facets=build_id&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-build_id

build version
20180709124824 52.9.1
20181217101353 60.4.0 spike?
20181204174145 60.3.3 spike?
20181030083531 60.3.0

Comment 4

[Magnus Melin [:mkmelin]]

(I don't have any clue here.)

Comment 5

[Wayne Mery (:wsmwk)]

In the last two weeks, crash rate for signatures has decreased

• https://crash-stats.mozilla.org/signature/?signature=shutdownhang%20%7C%20_PR_MD_WAIT_CV%20%7C%20PR_Wait%20%7C%20PR_CWait%20%7C%20nsMsgCopy%3A%3ADoCopy&date=%3E%3D2019-09-09T12%3A04%3A00.000Z&date=%3C2019-12-09T12%3A04%3A00.000Z#graphs
• https://crash-stats.mozilla.org/signature/?signature=shutdownhang | _PR_MD_WAIT_CV | _PR_WaitCondVar | PR_Wait | PR_CWait | nsMsgCopy%3A%3ADoCopy&date=>%3D2019-09-09T12%3A04%3A00.000Z&date=<2019-12-09T12%3A04%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#graphs

while in the same two weeks, crash rate for the following have increased

• https://crash-stats.mozilla.com/signature/?signature=shutdownhang%20%7C%20ntdll.dll%20%7C%20kernel32.dll%20%7C%20_PR_MD_WAIT_CV%20%7C%20_PR_WaitCondVar%20%7C%20PR_Wait%20%7C%20PR_CWait%20%7C%20nsMsgCopy%3A%3ADoCopy&date=%3E%3D2019-11-09T13%3A24%3A00.000Z&date=%3C2019-12-09T13%3A24%3A00.000Z#graphs
• https://crash-stats.mozilla.com/signature/?signature=shutdownhang%20%7C%20kernelbase.dll%20%7C%20_PR_MD_WAIT_CV%20%7C%20_PR_WaitCondVar%20%7C%20PR_Wait%20%7C%20PR_CWait%20%7C%20nsMsgCopy%3A%3ADoCopy&date=%3E%3D2019-11-09T12%3A07%3A00.000Z&date=%3C2019-12-09T12%3A07%3A00.000Z#graphs

Comment 6

[Wayne Mery (:wsmwk)]

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

In the last two weeks, crash rate for signatures has decreased
...
while in the same two weeks, crash rate for the following have increased
....

That increase quickly changed to a decrease. And only the only crash in the top 200 containing nsMsgCopy::DoCopy is shutdownhang | _PR_MD_WAIT_CV | PR_Wait | PR_CWait | nsMsgCopy::DoCopy

Perhaps this too should wait on bug 1175168

Comment 7

[Wayne Mery (:wsmwk)]

At #35 for 78.8.1, still a significant crash.

Comment 8

[Magnus Melin [:mkmelin]]

Looking at the stack, this will be gone (or changed beyond recognition) with the new js send backend.

Comment 9

[Wayne Mery (:wsmwk)]

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

Looking at the stack, this will be gone (or changed beyond recognition) with the new js send backend.

If you mean smtp-js bug 1661694, it does not appear to be gone. We of course are not yet unthrottled for updates, but I estimate the crash rate to be the same for version 91 and 78 (calculations accounting for % of users on each version).

But maybe changed?

Comment 10

[Wayne Mery (:wsmwk)]

Is shutdownhang | PR_MD_WAIT_CV | PR_Wait | nsMsgCopy::DoCopy the same crash?

Comment 11

[Magnus Melin [:mkmelin]]

I meant bug 1211292 - seems the crashing part is still there though so it just changed.

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

Is shutdownhang | PR_MD_WAIT_CV | PR_Wait | nsMsgCopy::DoCopy the same crash?

Should be yes.

Comment 12

[Wayne Mery (:wsmwk)]

Adding Mac signatures too

Comment 13

[Worcester12345]

Thunderbird 91.1.0 Crash Report [@ shutdownhang | PR_MD_WAIT_CV | PR_Wait | nsMsgCopy::DoCopy ]
bp-5f975f3b-b63f-4d11-8260-0523b0210916

Comment 14

[Wayne Mery (:wsmwk)]

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

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

Looking at the stack, this will be gone (or changed beyond recognition) with the new js send backend.

If you mean smtp-js bug 1661694, it does not appear to be gone. We of course are not yet unthrottled for updates, but I estimate the crash rate to be the same for version 91 and 78 (calculations accounting for % of users on each version).

But maybe changed?

Judging by the past week, version 91's crash rate is doubled compared to version 78

Comment 15

[Wayne Mery (:wsmwk)]

And #15 rank, compared to #38 for version 78.

Comment 16

[Wayne Mery (:wsmwk)]

(In reply to Worcester12345 from comment #13)

Thunderbird 91.1.0 Crash Report [@ shutdownhang | PR_MD_WAIT_CV | PR_Wait | nsMsgCopy::DoCopy ]
bp-5f975f3b-b63f-4d11-8260-0523b0210916

worcester12345, do you have any crashes since December 1?

Comment 17

[Worcester12345]

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

(In reply to Worcester12345 from comment #13)

Thunderbird 91.1.0 Crash Report [@ shutdownhang | PR_MD_WAIT_CV | PR_Wait | nsMsgCopy::DoCopy ]
bp-5f975f3b-b63f-4d11-8260-0523b0210916

worcester12345, do you have any crashes since December 1?

If I did, I would have submitted them (when it lets me).

Comment 18

[Wayne Mery (:wsmwk)]

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

I meant bug 1211292 - seems the crashing part is still there though so it just changed.

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

Is shutdownhang | PR_MD_WAIT_CV | PR_Wait | nsMsgCopy::DoCopy the same crash?

Should be yes.

In beta 100, the crash ranks only #60 which is a step in the right direction
In beta 101, the crash ranks #64

Comment 19

[Wayne Mery (:wsmwk)]

crash ranks in top 10 when combining crash signatures

Comment 20

[Wayne Mery (:wsmwk)]

Another signature [@ shutdownhang | _PR_MD_WAIT_CV | _PR_WaitCondVar | PR_Wait | nsMsgCopy::DoCopy ] bp-27503be4-1e0a-44a3-8e64-ae3e20230316. Account information below.

Should I have the user, Jeff, try imap-js ?

ID
Incoming server Outgoing servers
Name Connection security Authentication method
Name Connection security Authentication method Default?
account1
(pop3) incoming.verizon.net:995 SSL passwordCleartext
smtp.gmail.com:587 alwaysSTARTTLS OAuth2 true
account4
(pop3) pop.bongoboy.com:110 plain passwordCleartext
smtp.gmail.com:587 alwaysSTARTTLS OAuth2 true

smtp.gmail.com:587 	alwaysSTARTTLS 	OAuth2 	false

account5
(pop3) pop.bongoboy.com:110 plain passwordCleartext
smtp.googlemail.com:465 SSL passwordCleartext true
account6
(pop3) pop.bongoboy.com:110 plain passwordCleartext
smtp.bongoboy.com:587 plain passwordCleartext true
account9
(pop3) mail.taconicarts.com:995 SSL passwordCleartext
mail.taconicarts.com:465 SSL passwordCleartext true
account11
(pop3) pop.bongoboy.com:110 plain passwordCleartext
smtp.gmail.com:587 alwaysSTARTTLS OAuth2 true
account13
(none) Local Folders plain passwordCleartext
account14
(rss) Feeds plain passwordCleartext
account15
(nntp) news.mozilla.org:119 plain passwordCleartext
smtp.gmail.com:587 alwaysSTARTTLS OAuth2 true
account17
(rss) News & Blogs plain passwordCleartext
account19
(nntp) news.eternal-september.org:119 plain passwordCleartext
smtp.gmail.com:587 alwaysSTARTTLS OAuth2 true
account24
(imap) imap.googlemail.com:993 SSL OAuth2
smtp.googlemail.com:465 SSL passwordCleartext true
account27
(pop3) pop.nocountryforsanemen.com:110 plain passwordCleartext
smtp.nocountryforsanemen.com:587 plain passwordCleartext true
account30
(pop3) pop3.frontier.com:995 SSL passwordCleartext
smtp.frontier.com:465 plain passwordCleartext true
account32
(imap) imap.gmail.com:993 SSL OAuth2
smtp.gmail.com:465 SSL OAuth2 true
account33
(imap) imap.gmail.com:993 SSL OAuth2
smtp.gmail.com:587 alwaysSTARTTLS OAuth2 true
account38
(pop3) pop.gmail.com:995 SSL OAuth2
smtp.gmail.com:587 alwaysSTARTTLS OAuth2 true
account39
(pop3) mail.kalhaven.org:110 alwaysSTARTTLS passwordCleartext
mail.kalhaven.org:465 SSL passwordCleartext true
account40
(pop3) pop.gmail.com:995 SSL OAuth2
smtp.gmail.com:465 SSL OAuth2 true
account41
(imap) imap.gmail.com:993 SSL OAuth2
smtp.gmail.com:465 SSL OAuth2 true
account44
(imap) outlook.office365.com:993 SSL OAuth2
smtp.office365.com:587 alwaysSTARTTLS OAuth2 true

Comment 21

[Wayne Mery (:wsmwk)]

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

Another signature [@ shutdownhang | _PR_MD_WAIT_CV | _PR_WaitCondVar | PR_Wait | nsMsgCopy::DoCopy ] bp-27503be4-1e0a-44a3-8e64-ae3e20230316. Account information below.

The crash signature fits with the user's description "I had just sent one with several attachments. TB sent the mail but then hung for a while and told me it could not save a copy in the sent folder. I gave it whatever it wanted but it just hung there. I tried to close the program but it refused to cooperate so I closed it from within task manager. "

Comment 22

[Magnus Melin [:mkmelin]]

Should I have the user, Jeff, try imap-js ?

It may be stuck waiting to an OnStopCopy which won't ever happen after imap shut down. Unclear if imap-js would help but perhaps.

Comment 23

[Wayne Mery (:wsmwk)]

https://mzl.la/3tczknz

Comment 24

[Wayne Mery (:wsmwk)]

Attachment: graph six months of crashes

crash rate in version 115 is doubled

Comment 25

[Wayne Mery (:wsmwk)]

reporter of bp-06016686-dcf1-4c0c-bd79-a26710231211 states
"I got this message right adter I closed Thunderbird, so I don't know about the crash. But I have been having other problems. 1) messages are sent but not saved in my Sent folder
2) I keep getting messagees that say: " Non overridable TLS error occurred.Handshake error or probably the TLS verdsion or certificate used by serverimap.rcn.com is incompatible
Please correct these problems -- or let me know what I need to do."

Comment 26

[dxtr80]

Hi all,

This ticket is connected to a ticket reported for over 15 years (this one 6y ago) and is still unresolved.

This is a major feature of TB and should be resolved rapidly. Applies to TB 115.10.1.

Robert

Comment 27

[gene smith]

(In reply to dxtr80 from comment #26)

This ticket is connected to a ticket reported for over 15 years (this one 6y ago) and is still unresolved.
This is a major feature of TB and should be resolved rapidly. Applies to TB 115.10.1.

Most of the comments above are about random crash reports with not a lot of direct info from the users. Can you be more specific as to what issue you are seeing, how often it occurs and if there is a way to consistently duplicate the bug?

I suspect this is about problems when a message is saved to imap "sent" folder. FWIW, some good improvements were made to that about a year ago that are now in 115.

If it's about "saving to sent folder", I see that your email address is gmail. If you send messages via gmail's servers, I think gmail automatically puts what you sent into the imap "Sent" folder. So TB's feature to save to sent folder can be switched off when using gmail, I think.

Comment 28

[Wayne Mery (:wsmwk)]

dxtr ?

Comment 29

[dxtr80]

Hi All, I put my comment here, cause I thought that is the root cause 406929.
@gene smith I'm using 3 accounts one is Gmail, and two others are IMAP servers - same issue with the sent folder visible there as well.

Comment 30

[Wayne Mery (:wsmwk)]

Perhaps related mozilla::dom::workerinternals::RuntimeService::CrashIfHanging bp-b7508828-6e5b-4bef-9924-678210241012