Thunderbird Crash sending mail in shutdownhang | _PR_MD_WAIT_CV | _PR_WaitCondVar | PR_Wait | PR_CWait | nsMsgCopy::DoCopy - Error saving to Sent folder
Categories
(MailNews Core :: Composition, defect)
Tracking
(thunderbird_esr60 wontfix, thunderbird_esr78 wontfix, thunderbird_esr91+ wontfix, thunderbird_esr102 affected, thunderbird_esr115+ affected)
People
(Reporter: wsmwk, Unassigned)
References
(Blocks 1 open bug)
Details
(4 keywords)
Crash Data
Attachments
(2 files)
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
|
Reporter | |
Comment 1•5 years ago
|
||
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.
|
|
Reporter | |
Comment 2•5 years ago
|
||
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
|
|
Reporter | |
Comment 3•5 years ago
•
|
||
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
build version
20180709124824 52.9.1
20181217101353 60.4.0 spike?
20181204174145 60.3.3 spike?
20181030083531 60.3.0
|
|
Reporter | |
Comment 5•4 years ago
•
|
||
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
|
|
Reporter | |
Updated•4 years ago
|
|
|
Reporter | |
Comment 6•4 years ago
|
||
(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
|
|
Reporter | |
Comment 7•3 years ago
|
||
At #35 for 78.8.1, still a significant crash.
|
||
Comment 8•3 years ago
|
||
Looking at the stack, this will be gone (or changed beyond recognition) with the new js send backend.
|
|
Reporter | |
Comment 9•3 years ago
|
||
(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?
|
|
Reporter | |
Comment 10•3 years ago
|
||
Is shutdownhang | PR_MD_WAIT_CV | PR_Wait | nsMsgCopy::DoCopy the same crash?
|
|
||
Comment 11•3 years ago
|
||
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.
|
|
Reporter | |
Comment 12•3 years ago
|
||
Adding Mac signatures too
|
|
Reporter | |
Updated•3 years ago
|
|
||
Comment 13•3 years ago
•
|
||
Thunderbird 91.1.0 Crash Report [@ shutdownhang | PR_MD_WAIT_CV | PR_Wait | nsMsgCopy::DoCopy ]
bp-5f975f3b-b63f-4d11-8260-0523b0210916
|
|
Reporter | |
Comment 14•3 years ago
|
||
(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
|
|
Reporter | |
Comment 15•3 years ago
|
||
And #15 rank, compared to #38 for version 78.
|
|
Reporter | |
Comment 16•2 years ago
|
||
(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•2 years ago
|
||
(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-0523b0210916worcester12345, do you have any crashes since December 1?
If I did, I would have submitted them (when it lets me).
|
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 18•2 years ago
|
||
(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
|
|
Reporter | |
Comment 19•1 year ago
|
||
crash ranks in top 10 when combining crash signatures
|
|
Reporter | |
Comment 20•1 year ago
|
||
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
|
|
Reporter | |
Comment 21•1 year ago
|
||
(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•1 year ago
|
||
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.
|
||
Updated•1 year ago
|
|
|
Reporter | |
Comment 23•4 months ago
|
||
|
|
Reporter | |
Updated•4 months ago
|
|
|
Reporter | |
Comment 24•4 months ago
|
||
crash rate in version 115 is doubled
|
|
Reporter | |
Comment 25•4 months ago
|
||
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."
Description
•