Closed Bug 556355 Opened 10 years ago Closed Last year

crash @ nsMsgComposeAndSend::GatherMimeAttachments (with engimail)

Categories

(MailNews Core :: Attachments, defect, critical)

x86
All
defect
Not set
critical

Tracking

(thunderbird60 fixed, thunderbird61 fixed)

RESOLVED FIXED
Thunderbird 61.0
Tracking Status
thunderbird60 --- fixed
thunderbird61 --- fixed

People

(Reporter: wsmwk, Assigned: jorgk)

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

crash [@ nsMsgComposeAndSend::GatherMimeAttachments()]
#210 crash for v3.0.3
none of the first 10 have email addresses

bp-2009bea7-6e99-4ce8-bb35-afe202100330
0	thunderbird.exe	nsMsgComposeAndSend::GatherMimeAttachments	 mailnews/compose/src/nsMsgSend.cpp:780
1	thunderbird.exe	nsMsgAttachmentHandler::UrlExit	mailnews/compose/src/nsMsgAttachmentHandler.cpp:1323
2	thunderbird.exe	FetcherURLDoneCallback	mailnews/compose/src/nsMsgAttachmentHandler.cpp:534
3	thunderbird.exe	nsURLFetcher::OnStopRequest	mailnews/compose/src/nsURLFetcher.cpp:327
4	thunderbird.exe	nsDocumentOpenInfo::OnStopRequest	uriloader/base/nsURILoader.cpp:323
5	thunderbird.exe	nsStreamConverter::OnStopRequest	mailnews/mime/src/nsStreamConverter.cpp:1094
6	thunderbird.exe	nsMsgProtocol::OnStopRequest	mailnews/base/util/nsMsgProtocol.cpp:401
7	thunderbird.exe	nsMailboxProtocol::OnStopRequest	mailnews/local/src/nsMailboxProtocol.cpp:380
8	thunderbird.exe	nsInputStreamPump::OnStateStop	netwerk/base/src/nsInputStreamPump.cpp:576
9	thunderbird.exe	nsInputStreamPump::OnInputStreamReady	netwerk/base/src/nsInputStreamPump.cpp:401
10	xpcom_core.dll	nsInputStreamReadyEvent::Run	xpcom/io/nsStreamUtils.cpp:111
most of the crashes are still the same, eg
bp-b1a5ec2a-1615-40d4-946c-0908f2110110
EXCEPTION_ACCESS_VIOLATION_READ
0x0
0	thunderbird.exe	nsMsgComposeAndSend::GatherMimeAttachments	mailnews/compose/src/nsMsgSend.cpp:772
1	thunderbird.exe	nsMsgAttachmentHandler::UrlExit	mailnews/compose/src/nsMsgAttachmentHandler.cpp:1315
2	thunderbird.exe	FetcherURLDoneCallback	mailnews/compose/src/nsMsgAttachmentHandler.cpp:534
3	thunderbird.exe	nsURLFetcher::OnStopRequest	mailnews/compose/src/nsURLFetcher.cpp:327
4	thunderbird.exe	nsDocumentOpenInfo::OnStopRequest	uriloader/base/nsURILoader.cpp:323
5	thunderbird.exe	nsStreamConverter::OnStopRequest	mailnews/mime/src/nsStreamConverter.cpp:1116
6	thunderbird.exe	nsMsgProtocol::OnStopRequest	mailnews/base/util/nsMsgProtocol.cpp:401
7	thunderbird.exe	nsMailboxProtocol::OnStopRequest	mailnews/local/src/nsMailboxProtocol.cpp:381 

however, bp-8c2a605d-fd7d-44f0-8700-16ded2101216 is slightly different
0	thunderbird-bin	nsMsgComposeAndSend::GatherMimeAttachments	mailnews/compose/src/nsMsgSend.cpp:1143
1	thunderbird-bin	nsMsgComposeAndSend::HackAttachments	mailnews/compose/src/nsMsgSend.cpp:2752
2	thunderbird-bin	nsMsgComposeAndSend::Init	mailnews/compose/src/nsMsgSend.cpp:3451
3	thunderbird-bin	nsMsgComposeAndSend::CreateAndSendMessage	mailnews/compose/src/nsMsgSend.cpp:4293
OS: Windows Vista → All
Crash Signature: [@ nsMsgComposeAndSend::GatherMimeAttachments()]
bp-f8e01141-9256-4529-8e21-b33432120621 v12.0.1
bp-13c75270-9b32-4ffc-9374-f3aba2120620 v13.0.1
Crash Signature: [@ nsMsgComposeAndSend::GatherMimeAttachments()] → [@ nsMsgComposeAndSend::GatherMimeAttachments()] [@ nsMsgComposeAndSend::HackAttachments ]
joshua, 
would you agree bp-5be3e0aa-9b2a-432e-8236-73cee2121202 signature nsMsgComposeAndSend::Fail(unsigned int, wchar_t const*, unsigned int*) the same issue?  

likewise bp-ddb4d039-872f-4a27-9139-f2adc2121204 nsMsgComposeAndSend::Fail
bp-6f549746-4136-4093-a3a6-d837c2130707
0		@0x410837d	
1	xul.dll	nsMsgComposeAndSend::GatherMimeAttachments	mailnews/compose/src/nsMsgSend.cpp:1043
2	xul.dll	nsMsgComposeAndSend::HackAttachments	mailnews/compose/src/nsMsgSend.cpp:2665
3	xul.dll	nsMsgComposeAndSend::Init	mailnews/compose/src/nsMsgSend.cpp:3380
4	xul.dll	nsMsgComposeAndSend::CreateAndSendMessage	mailnews/compose/src/nsMsgSend.cpp:4220
5	xul.dll	nsMsgCompose::_SendMsg	mailnews/compose/src/nsMsgCompose.cpp:1148
6	xul.dll	nsMsgCompose::SendMsg	mailnews/compose/src/nsMsgCompose.cpp:1342 

hg@0 1023FAIL:
hg@0 1024 if (toppart)
hg@0 1025 delete toppart;
mconley@13187 1026 toppart = nullptr;
mconley@13187 1027 mainbody = nullptr;
mconley@13187 1028 maincontainer = nullptr;
hg@0 1029
hg@0 1030 PR_FREEIF(headers);
hg@0 1031 if (in_file)
hg@0 1032 {
hg@0 1033 PR_Close (in_file);
mconley@13187 1034 in_file = nullptr;
hg@0 1035 }
hg@0 1036
hg@0 1037 if (shouldDeleteDeliveryState)
hg@0 1038 {
ayg@13278 1039 if (NS_FAILED(status))
hg@0 1040 {
hg@0 1041 m_status = status;
hg@0 1042 nsresult ignoreMe;
mconley@13187 1043 Fail (status, nullptr, &ignoreMe); 

crash predates mconley's bug 776630 version 17 patch.
I seem to be able to reproduce this bug by entering my gpg passphrase wrong three times after triggering sending a message.

tb 24.3.0 on gentoo, debugging symbols and core dumps enabled.

This is part of a backtrace:

#0  0x000000383540fd5b in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x00007f42745ec386 in nsProfileLock::FatalSignalHandler (signo=11, info=0x7fff9a923170, context=0x7fff9a923040) at /mnt/pd/var-tmp-portage/portage/mail-client/thunderbird-24.3.0/work/comm-esr24/tbird/mozilla/toolkit/profile/nsProfileLock.cpp:180
#2  <signal handler called>
#3  0x00007f424a735d08 in ?? ()
#4  0x00007f4275129a1c in nsMsgComposeAndSend::Fail (this=0x7f42322feb20, aFailureCode=NS_ERROR_ABORT, aErrorMsg=<optimized out>, aResult=0x7fff9a9236e0)
    at /mnt/pd/var-tmp-portage/portage/mail-client/thunderbird-24.3.0/work/comm-esr24/mailnews/compose/src/nsMsgSend.cpp:3695
#5  0x00007f42751311b0 in nsMsgComposeAndSend::GatherMimeAttachments (this=0x7f42322feb20) at /mnt/pd/var-tmp-portage/portage/mail-client/thunderbird-24.3.0/work/comm-esr24/mailnews/compose/src/nsMsgSend.cpp:1013
#6  0x00007f4275133264 in nsMsgComposeAndSend::HackAttachments (this=this@entry=0x7f42322feb20, attachments=attachments@entry=0x0, preloadedAttachments=preloadedAttachments@entry=0x0)
    at /mnt/pd/var-tmp-portage/portage/mail-client/thunderbird-24.3.0/work/comm-esr24/mailnews/compose/src/nsMsgSend.cpp:2634
#7  0x00007f4275133841 in nsMsgComposeAndSend::Init (this=this@entry=0x7f42322feb20, aUserIdentity=aUserIdentity@entry=0x7f424adfc3a0, aAccountKey=aAccountKey@entry=0x7f421b760bf0 "account1", fields=fields@entry=0x7f4230760000, sendFile=sendFile@entry=0x0, 
    digest_p=digest_p@entry=false, dont_deliver_p=dont_deliver_p@entry=false, mode=mode@entry=0, msgToReplace=msgToReplace@entry=0x0, attachment1 [details] [diff] [review]_type=attachment1 [details] [diff] [review]_type@entry=0x7f4275eeacca "text/plain", attachment1 [details] [diff] [review]_body=..., attachments=attachments@entry=0x0, 
    preloaded_attachments=preloaded_attachments@entry=0x0, password=password@entry=0x7f4276fc0cb8 <gNullChar> "", aOriginalMsgURI=..., aType=aType@entry=2)
    at /mnt/pd/var-tmp-portage/portage/mail-client/thunderbird-24.3.0/work/comm-esr24/mailnews/compose/src/nsMsgSend.cpp:3337
#8  0x00007f427513399f in nsMsgComposeAndSend::CreateAndSendMessage (this=0x7f42322feb20, aEditor=0x0, aUserIdentity=0x7f424adfc3a0, aAccountKey=0x7f421b760bf0 "account1", fields=0x7f4230760000, digest_p=<optimized out>, dont_deliver_p=false, mode=0, msgToReplace=0x0, 
    attachment1 [details] [diff] [review]_type=0x7f4275eeacca "text/plain", attachment1 [details] [diff] [review]_body=..., attachments=0x0, preloaded_attachments=0x0, parentWindow=0x7f41e48d2820, progress=0x7f422bac5520, aListener=0x7f41ff6b8b08, password=0x7f4276fc0cb8 <gNullChar> "", aOriginalMsgURI=..., aType=2)
    at /mnt/pd/var-tmp-portage/portage/mail-client/thunderbird-24.3.0/work/comm-esr24/mailnews/compose/src/nsMsgSend.cpp:4148
#9  0x00007f4275118849 in nsMsgCompose::_SendMsg (this=this@entry=0x7f41e48e9640, deliverMode=deliverMode@entry=0, identity=identity@entry=0x7f424adfc3a0, accountKey=accountKey@entry=0x7f421b760bf0 "account1", entityConversionDone=entityConversionDone@entry=true)
    at /mnt/pd/var-tmp-portage/portage/mail-client/thunderbird-24.3.0/work/comm-esr24/mailnews/compose/src/nsMsgCompose.cpp:1140
#10 0x00007f4275118d74 in nsMsgCompose::SendMsg (this=0x7f41e48e9640, deliverMode=0, identity=0x7f424adfc3a0, accountKey=0x7f421b760bf0 "account1", aMsgWindow=<optimized out>, progress=0x7f422bac5520)
    at /mnt/pd/var-tmp-portage/portage/mail-client/thunderbird-24.3.0/work/comm-esr24/mailnews/compose/src/nsMsgCompose.cpp:1330
#11 0x00007f42755a69b4 in NS_InvokeByIndex (that=<optimized out>, methodIndex=<optimized out>, paramCount=<optimized out>, params=<optimized out>)
    at /mnt/pd/var-tmp-portage/portage/mail-client/thunderbird-24.3.0/work/comm-esr24/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:164
(In reply to ole.langbehn from comment #5)
> I seem to be able to reproduce this bug by entering my gpg passphrase wrong
> three times after triggering sending a message.

oh, and no attachments except gpg signature.
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Crash Signature: [@ nsMsgComposeAndSend::GatherMimeAttachments()] [@ nsMsgComposeAndSend::HackAttachments ] → [@ nsMsgComposeAndSend::GatherMimeAttachments()] [@ nsMsgComposeAndSend::HackAttachments ] [@ nsMsgComposeAndSend::GatherMimeAttachments]
Thunderbird 52.0.1, Windows 7, gpg 2.0.30 (gpg4win 2.3.3), Enigmail 1.9.6.1

I'm seeing these crashes since updating to TB 52.0.1, pretty much once a day.

bp-927a298e-49b8-425e-ab6c-0134f0170418
bp-3b5465c7-e026-4904-8dcb-912fe0170418
bp-1e73b758-bd8c-46ff-b662-355042170412

Bug 1323515 is possibly related.

Thunderbird usage hasn't changed compared to 52.0 and 45.x. The problem is not exactly reproducible.

Symptoms:
- Thunderbird 'hangs' when attempting to open an encrypted message
- Thunderbird 'hangs' when attempting to send an encrypted message
- multiple gpg.exe processes in Windows task manager

Upon shutting down Thunderbird it crashes.
Killing the orphan gpg.exe processes and re-starting Thunderbird fixes the problem, at least temporarily.
A similar problem is also seen on MacOS with Thunderbird 52.1.0.
https://support.mozilla.org/en-US/questions/1159460
Crashes are also seen with TB 52.1.1 on Win10.
The crashed reported in comment #8 are all from nsMsgSend.cpp:1025:
https://dxr.mozilla.org/comm-central/rev/ff32dbcafcd4e82afb672b30fb0a5ee817083291/mailnews/compose/src/nsMsgSend.cpp#1025

So something went wrong and trying to call Fail() at
https://dxr.mozilla.org/comm-central/rev/ff32dbcafcd4e82afb672b30fb0a5ee817083291/mailnews/compose/src/nsMsgSend.cpp#3483
crashes completely.

I don't see any obvious reason why that would crash. Someone running Enigmail would have to debug this. Multiple gpg.exe processes doesn't sound good.

Please understand that TB is a volunteer-based project, so someone needs to volunteer to investigate this. There should be suitable people in the crypto-community with the right skill set. The TB core maintainers don't have resources to investigate add-on triggered crashes.
Multiple processes of gpg.exe only stem from previous attempts to send something (which somehow fails). There's some exception that I could not yet find (since I don't have these crashes) that cause subprocess.jsm to fail.

Interestingly, this only seems to happen with TB 52.x. TB 45 and TB 54b are not affected by this.
(In reply to Patrick Brunschwig from comment #12)
> Interestingly, this only seems to happen with TB 52.x. TB 45 and TB 54b are
> not affected by this.

I also had a different type of crash with Thunderbird 45 - see bug 1323515.

And I've seen Thunderbird hanging upon *opening* an encrypted message.
Just to add this:
I believe the problem occurs upon or after sending encrypted messages with an attachment using PGP/MIME.
Win7, Thunderbird 52.1.1, Enigmail 1.9.6.1, gpg4win 2.3.3 (with gnupg 2.0.30).
I could reproduce the problem as follows:
1. Send a PGP/MIME encrypted message with a 3.7 MB attachment - no problem.
2. Once again - end a PGP/MIME encrypted message with a 3.7 MB attachment - no problem.
3. Right-click the previously sent message - Edit as new.
   The encrypted message does not open, and there are two orphan gpg2.exe processes.

The error console shows:
DEPRECATION WARNING: Encoding to non-UTF-8 values is obsolete
You may find more details about this deprecation at: http://bugzilla.mozilla.org/show_bug.cgi?id=790855
resource://gre/components/mimeJSComponents.js 443 MimeConverter.prototype.encodeMimePartIIStr_UTF8
resource://enigmail/subprocess.jsm 1113 subprocess_win32/<.wait
resource://enigmail/mimeDecrypt.jsm 296 EnigmailMimeDecrypt.prototype.onStopRequest

mimeDecrypt.jsm: caught exception: TypeError
Message: 'this.msgWindow.msgHeaderSink is null'
File:    resource://enigmail/mimeDecrypt.jsm
Line:    326
Stack:   EnigmailMimeDecrypt.prototype.displayStatus@resource://enigmail/mimeDecrypt.jsm:326:11
EnigmailMimeDecrypt.prototype.onStopRequest@resource://enigmail/mimeDecrypt.jsm:307:5

4. Attempting to close Thunderbird. It won't close but hangs, and then crashes.
bp-759355d9-da47-4435-9165-544460170528
Contrary to previous statements, Thunderbird 54.0b2 on Linux does not appear to be immune against this problem.
At some point Thunderbird also failed to open the encrypted message and crashed upon shutdown.
bp-e16f644a-f145-439e-b9a0-e8e6c0170528
Thanks, this may be a hint:

mimeDecrypt.jsm: caught exception: TypeError
Message: 'this.msgWindow.msgHeaderSink is null'
File:    resource://enigmail/mimeDecrypt.jsm
Line:    326
The exception is only logged. It's correctly caught and should not result in something breaking.

However, the fact that msgWindow.msgHeaderSink is null is strange.
(In reply to Christian Riechers from comment #15)
> Win7, Thunderbird 52.1.1, Enigmail 1.9.6.1, gpg4win 2.3.3 (with gnupg
> 2.0.30).

I tried with enigmail-1.9.8-a4 and did not see the problem anymore.
Thunderbird 52.2.1 Crash Report [@ nsMsgComposeAndSend::GatherMimeAttachments ]

Install Time 	2017-06-28 19:10:02
Release Channel 	release
Build ID 	20170622064432
OS 	Windows XP
OS Version 	5.1.2600 Service Pack 3
Build Architecture 	x86

Enigmail Version 1.9.7 (20170513-1610)
gpgwrap (Gpg4win) 2.3.1 ;C:\Programme\GNU\GnuPG\gpg2.exe
gpg (GnuPG) 2.0.30 (Gpg4win 2.3.1)
libgcrypt 1.6.5

bp-dfc8cace-6cb5-4eb7-b9e9-71a2d0170705
=============================


0 	xul.dll 	nsMsgComposeAndSend::GatherMimeAttachments() 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:1025
1 	xul.dll 	nsMsgComposeAndSend::HackAttachments(nsIArray*, nsIArray*) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:2574
2 	xul.dll 	nsMsgComposeAndSend::Init(nsIMsgIdentity*, char const*, nsMsgCompFields*, nsIFile*, bool, bool, int, nsIMsgDBHdr*, char const*, nsACString_internal const&, nsIArray*, nsIArray*, char const*, nsACString_internal const&, int) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:3156
3 	xul.dll 	nsMsgComposeAndSend::CreateAndSendMessage(nsIEditor*, nsIMsgIdentity*, char const*, nsIMsgCompFields*, bool, bool, int, nsIMsgDBHdr*, char const*, nsACString_internal const&, nsIArray*, nsIArray*, mozIDOMWindowProxy*, nsIMsgProgress*, nsIMsgSendListener*, char const*, nsACString_internal const&, int) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:4051
4 	xul.dll 	nsMsgCompose::SendMsgToServer(int, nsIMsgIdentity*, char const*) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgCompose.cpp:1241
5 	xul.dll 	nsMsgCompose::SendMsg(int, nsIMsgIdentity*, char const*, nsIMsgWindow*, nsIMsgProgress*) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgCompose.cpp:1460
6 	xul.dll 	NS_InvokeByIndex 	xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_msvc.asm:54
7 	xul.dll 	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 	js/xpconnect/src/XPCWrappedNative.cpp:1344
8 	xul.dll 	xpc::NonVoidStringToJsval(JSContext*, mozilla::dom::DOMString&, JS::MutableHandle<JS::Value>) 	js/xpconnect/src/xpcpublic.h:362
9 	xul.dll 	xpc::NonVoidStringToJsval(JSContext*, mozilla::dom::DOMString&, JS::MutableHandle<JS::Value>) 	js/xpconnect/src/xpcpublic.h:368
10 	xul.dll 	nsAttrValue::ToString(mozilla::dom::DOMString&) 	dom/base/nsAttrValue.h:521
11 	xul.dll 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:999
12 	xul.dll 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:999
13 	xul.dll 	XPCWrappedNative_Trace(JSTracer*, JSObject*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:598
14 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:459
15 	xul.dll 	InternalCall 	js/src/vm/Interpreter.cpp:504
16 	xul.dll 	Interpret 	js/src/vm/Interpreter.cpp:2922
17 	xul.dll 	Interpret 	js/src/vm/Interpreter.cpp:2922
18 	mozglue.dll 	arena_malloc_small 	memory/mozjemalloc/jemalloc.c:4196
19 	mozglue.dll 	arena_dalloc_small 	memory/mozjemalloc/jemalloc.c:4575
Robert, newer enigmail has a fix
Since Aug 2 (a Wednesday), crash rate for nsMsgComposeAndSend::GatherMimeAttachments is up 4x [1]. This increase does NOT appear to coincide with a specific Thunderbird release date. Spot checking several crashes all three have enigmail 1.9.8.2  (date of release is August 21) or release 1.9.8.1 - so does not seem to correspond to any enigmail releases.  But afaict Aug 2 also does not correlate to any thunderbird release activity.  A few crashes clearly have gone through cycle collector.

Some crash comments:
- Had to kill GPG child process because password window did not appear and Thunderbird was hanging. Since some weeks this happens quite often when trying to send mail with encryption or signature via Enigmail plugin. bp-43a3a5a7-dd29-494a-85bc-381210170902
- Trying to send a non-encrypted email from an account with encryption enabled. Error message immediately before crash said "Encryption command failed" or similar.
- Unchecked Signature icon, received "Encrpyption command failed," error before TB crashed. Using Enigmail plug-in. bp-7c8cac22-fc4b-411e-a236-db5440170826
- tried sending too large attachments, then crashed minute later bp-242fc5f4-4aa2-489a-91d0-f61d80170822

Patrick, can you ahve a look?

[1] See the graph at https://crash-stats.mozilla.com/signature/?signature=nsMsgComposeAndSend%3A%3AGatherMimeAttachments&date=%3E%3D2017-06-05T02%3A42%3A42.000Z&date=%3C2017-09-05T02%3A42%3A42.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1#graphs
Flags: needinfo?(patrick)
The increased crash rate corresponds pretty well to the release of Enigmail 1.9.8.1 (July 31).

Version 1.9.8.1 contains major differences to 1.9.7 (a new subprocess library that I took from Firefox because the old one stopped working on TB 52 in some cases), so I suspect that this is the cause for the crashes. 1.9.8.2 is only a minor bugfix release - I'd treat it equal to 1.9.8.1.

I can try to change the sequence of the commands in Enigmail to guarantee that nsMsgComposeAndSend::GatherMimeAttachments has completed before Enigmail launches gpg, such that I can catch possible hickups from gpg.

The strange thing is that the new library seems to work fine in general -- otherwise we'd also see crashes during PGP/MIME decryption.
Flags: needinfo?(patrick)
I checked the source code of nsMsgSend.cpp. We crash here:

  if (shouldDeleteDeliveryState)
  {
    if (NS_FAILED(status))
    {
      m_status = status;
      nsresult ignoreMe;
      Fail(status, nullptr, &ignoreMe);  <----- CRASH
    }
  }


It looks to me like there is some kind of problem during message sending, leading to crash in the Fail() function.

But is this supposed to crash at all? I'm getting the impression that we crash because somewhere further up we get out of memory.


In any case, I uploaded a new version of Enigmail to the beta channel that moves all calls to gpg to the end, when GatherMimeAttachments() is certainly done. If we still get crashes, then it's something else.
Enigmail 1.9.8.3 has been approved today. I'm hoping that this will reduce the crash rate.
I think the crash rate didn't go down. But given the way I changed Enigmail now, I don't think that it's the only cause of the crash. It's possible that Enigmail would still increase memory consumption to some degree, but the crashes happen during GatherMimeAttachments() -- which is before most of Enigmail's work.
(In reply to Patrick Brunschwig from comment #27)
> I think the crash rate didn't go down. But given the way I changed Enigmail
> now, I don't think that it's the only cause of the crash. It's possible that
> Enigmail would still increase memory consumption to some degree, but the
> crashes happen during GatherMimeAttachments() -- which is before most of
> Enigmail's work.

Along those lines...

"... two attachments. Sending unencrypted but bcrash occures saying encryption fails." bp-14e227c4-2885-4938-8333-4ace50180126

"It said there was an encryption problem, but the recipient did not have PGP, so no encryption was in use."  bp-3e6cc239-935d-423f-96b4-c01d70180209
My first TB-Crash in Windows 10 - Masterpassword is activated, only one Mail-Account is configurated IMAP GMX: 
(no POP3 nor UseNet Accounts configured)

Thunderbird 52.6.0 Crash Report [@ nsMsgComposeAndSend::GatherMimeAttachments ]

The only attachment file was the gpg-signature.

Name 	        Thunderbird
Version 	52.6.0
User-Agent 	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
Build-ID der Anwendung 	20180123185941

Plugins: No-Plugins
Addons:
Enigmail	1.9.9	true	{847b3a00-7ab1-11d4-8f02-006008948af5}
Get Partial Messages	0.3.3	true	{6C3323F8-7328-11DE-B11C-551356D89593}
Lightning	5.4.6	true	{e2fda1a4-762b-4020-b5ad-a41df1933103}
Mail Redirect	0.9.5	true	{CC3C233D-6668-41bc-AAEB-F3A1D1D594F5}
Zeig'sMir! (LookOut)	1.2.20	true	lookout@s3_fix_version
McAfee Anti-Spam Thunderbird Extension	3.0	false	msktbird@mcafee.com

gpg4win 3.0.3 installed: 
           pinentry-qt (pinentry) 1.1.0
           gpa 0.9.10
           gpg (GnuPG) 2.2.4
           libgcrypt 1.8.2

Windows 10 Home Build 16299.rs3_release.170928-1543
Intel Core Celeron CPU N3060 @ 1,60 GHz
RAM 4,00 GB (about 3,83 GB free)
HD: 800 GB free

https://crash-stats.mozilla.com/report/index/9d687ada-b1a1-4b82-b4d5-85bbd0180313
bp-9d687ada-b1a1-4b82-b4d5-85bbd0180313

Frame 	Module 	Signature 	Source
0 	xul.dll 	nsMsgComposeAndSend::GatherMimeAttachments() 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:1025
1 	xul.dll 	nsMsgComposeAndSend::HackAttachments(nsIArray*, nsIArray*) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:2564
2 	xul.dll 	nsMsgComposeAndSend::Init(nsIMsgIdentity*, char const*, nsMsgCompFields*, nsIFile*, bool, bool, int, nsIMsgDBHdr*, char const*, nsACString_internal const&, nsIArray*, nsIArray*, char const*, nsACString_internal const&, int) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:3146
3 	xul.dll 	nsMsgComposeAndSend::CreateAndSendMessage(nsIEditor*, nsIMsgIdentity*, char const*, nsIMsgCompFields*, bool, bool, int, nsIMsgDBHdr*, char const*, nsACString_internal const&, nsIArray*, nsIArray*, mozIDOMWindowProxy*, nsIMsgProgress*, nsIMsgSendListener*, char const*, nsACString_internal const&, int) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgSend.cpp:4041
4 	xul.dll 	nsMsgCompose::SendMsgToServer(int, nsIMsgIdentity*, char const*) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgCompose.cpp:1238
5 	xul.dll 	nsMsgCompose::SendMsg(int, nsIMsgIdentity*, char const*, nsIMsgWindow*, nsIMsgProgress*) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/mailnews/compose/src/nsMsgCompose.cpp:1459
6 	xul.dll 	NS_InvokeByIndex 	xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_msvc.asm:54
7 	xul.dll 	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 	js/xpconnect/src/XPCWrappedNative.cpp:1344
8 	xul.dll 	xpc::NonVoidStringToJsval(JSContext*, mozilla::dom::DOMString&, JS::MutableHandle<JS::Value>) 	js/xpconnect/src/xpcpublic.h:362
9 	xul.dll 	mozilla::dom::DOMDownloadManagerJSImpl::Remove(mozilla::dom::DOMDownload&, mozilla::ErrorResult&, JSCompartment*) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/objdir-tb/dom/bindings/DownloadsBinding.cpp:3123
10 	xul.dll 	mozilla::dom::ElementBinding::getAttribute 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/objdir-tb/dom/bindings/ElementBinding.cpp:635
11 	xul.dll 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1000
12 	xul.dll 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1000
13 	xul.dll 	XPCWrappedNative_Trace(JSTracer*, JSObject*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:598
14 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:459
15 	xul.dll 	InternalCall 	js/src/vm/Interpreter.cpp:504
16 	xul.dll 	Interpret 	js/src/vm/Interpreter.cpp:2922
17 	xul.dll 	Interpret 	js/src/vm/Interpreter.cpp:2922
18 	xul.dll 	ApplyOverflowClipping 	layout/generic/nsFrame.cpp:1970
19 	xul.dll 	nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder*, nsIFrame*, nsRect const&, nsDisplayListSet const&, unsigned int) 	layout/generic/nsFrame.cpp:2937
20 	xul.dll 	nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::SwapArrayElements<nsTArrayInfallibleAllocator, nsTArrayInfallibleAllocator>(nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>&, unsigned int, unsigned int) 	C:/builds/moz2_slave/tb-rel-c-esr52-w32_bld-0000000/build/objdir-tb/dist/include/nsTArray-inl.h:358
21 	mozglue.dll 	arena_dalloc 	memory/mozjemalloc/jemalloc.c:4703
see comment 28
Flags: needinfo?(m_kato)
Summary: crash [@ nsMsgComposeAndSend::GatherMimeAttachments()] → crash @ nsMsgComposeAndSend::GatherMimeAttachments (with engimail)
I guess that this is a kind of use-after-free since this pointer is 0xe5e5e5e5.  nsMsgComposeAndSend is released at this method, so this crash occurs.  So nsMsgComposeAndSend::GatherMimeAttachments() should use nsCOMPtr<nsIMsgSend> kungFuDeathGrip(this) at first.
Flags: needinfo?(m_kato)
OK, this follows Makoto-san's suggestion.

I couldn't help removing the code in nsMsgAttachmentHandler.cpp which makes no sense to me at all. That temp variable will go out of scope two lines later so it shouldn't have any effect. I can't go back to 2001 to check it though.

Further reading:
Bug 78967 comment #3, Bug 78967 comment #7.
I also sent HTML to a newsgroup with that code removed and saw no crash.
Attachment #8960365 - Flags: review?(m_kato)
Attachment #8960365 - Flags: review?(m_kato) → review+
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/96b445d6df36
Make sure the nsIMsgSend doesn't go away before we're done. r=m_kato
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 61.0
Can we backport this to TB 60? It seems that bug is quite frequent if Enigmail is used (no idea why).
Sure, if it is proven that it works. Wayne will watch the crash stats.
(In reply to Jorg K (GMT+1) from comment #35)
> Sure, if it is proven that it works. Wayne will watch the crash stats.

Perhaps Robert and others could test it?

To be proved will require specific testers who can reproduce with http://www.mozilla.org/en-US/thunderbird/channel/ because the crash rate is (for better or worse) too low on beta and nightly to know whether the patch is working. (beta has only 1-2 crashes per 3 month period).  Even the release channel crash rate is quite low.

That said, the patch looks simple.
So far this is only in TB 61 and Dailies are broken :-(
(In reply to Wayne Mery (:wsmwk) from comment #36)
> (In reply to Jorg K (GMT+1) from comment #35)
> > Sure, if it is proven that it works. Wayne will watch the crash stats.
> 
> Perhaps Robert and others could test it?
> 
> To be proved will require specific testers who can reproduce with
> http://www.mozilla.org/en-US/thunderbird/channel/ because the crash rate is
> (for better or worse) too low on beta and nightly to know whether the patch
> is working. (beta has only 1-2 crashes per 3 month period).  Even the
> release channel crash rate is quite low.

In bp-709e9c48-3c58-4ae3-9fe1-064d20180323 Robert writes "Cancel sending a mail before Pinentry GUI shows . Cancel Passwort input in Pinentry"

So if Robert has solid steps to reproduce and is willing to try a nightly build on a 64bit machine then https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/thunderbird-61.0a1.en-US.win64.installer.exe should have the patch.  Or there is a more convulted way to get more recent nightly build from https://treeherder.mozilla.org/#/jobs?repo=comm-central&selectedJob=170773605 - find "artifact uploaded: target.installer.exe" and download it.
Flags: needinfo?(Robert_Hartmann)
(In reply to Wayne Mery (:wsmwk) from comment #38)
> (In reply to Wayne Mery (:wsmwk) from comment #36)
> > (In reply to Jorg K (GMT+1) from comment #35)
> > > Sure, if it is proven that it works. Wayne will watch the crash stats.
> > 
> > Perhaps Robert and others could test it?
> > 
> > To be proved will require specific testers who can reproduce with
> > http://www.mozilla.org/en-US/thunderbird/channel/ because the crash rate is
> > (for better or worse) too low on beta and nightly to know whether the patch
> > is working. (beta has only 1-2 crashes per 3 month period).  Even the
> > release channel crash rate is quite low.
> 
> In bp-709e9c48-3c58-4ae3-9fe1-064d20180323 Robert writes "Cancel sending a
> mail before Pinentry GUI shows . Cancel Passwort input in Pinentry"
> 
> So if Robert has solid steps to reproduce and is willing to try a nightly
> build on a 64bit machine then
> https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/
> thunderbird-61.0a1.en-US.win64.installer.exe should have the patch.  Or
> there is a more convulted way to get more recent nightly build from
> https://treeherder.mozilla.org/#/jobs?repo=comm-
> central&selectedJob=170773605 - find "artifact uploaded:
> target.installer.exe" and download it.

My first Crash with that Daily-version (thunderbird-61.0a1.en-US.win64) 
occures very suddenly while downloading IMAP Mails.
https://bugzilla.mozilla.org/show_bug.cgi?id=1453518 Bug 1453518
bp-739e2c48-425c-4d8d-b8fa-c0d4f0180411.
bit with very different crash signature:
Crash in nssCertificate_Destroy | CERT_DestroyCertArray | NSS_CMSSignedData_ImportCerts | nsCMSMessage::CommonVerifySignature
Assignee: nobody → jorgk
(In reply to Wayne Mery (:wsmwk) from comment #38)
> In bp-709e9c48-3c58-4ae3-9fe1-064d20180323 Robert writes "Cancel sending a
> mail before Pinentry GUI shows . Cancel Passwort input in Pinentry"
> 
> So if Robert has solid steps to reproduce and is willing to try a nightly
> build on a 64bit machine then
> https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/
> thunderbird-61.0a1.en-US.win64.installer.exe should have the patch.  Or
> there is a more convulted way to get more recent nightly build from
> https://treeherder.mozilla.org/#/jobs?repo=comm-
> central&selectedJob=170773605 - find "artifact uploaded:
> target.installer.exe" and download it.

Reproducible same way "Cancel sending a mail before Pinentry GUI shows . Cancel Passwort input in Pinentry"

Win10 64bit, TB daily, Enigmal Nightly, TB-Masterpasswort active:

IMAP-Account + Enter Masterpassword
Write Email (to own adress)
choose encrypt + signed (OpenPGP)
press "send"
press "cancel"-Button in sending-Messagebox
After Pinentry-Window opens, press cancel there 

Thunderbird 61.0a1 Crash Report [@ nsMsgComposeAndSend::CreateAndSendMessage ]

Extensions
Name 	Version 	Enabled 	ID
Enigmail	2.1a1pre	true	{847b3a00-7ab1-11d4-8f02-006008948af5}
Lightning	6.3a1	false	{e2fda1a4-762b-4020-b5ad-a41df1933103}

bp-bca955cc-86b1-47c3-939c-3981c0180412

https://crash-stats.mozilla.com/report/index/bca955cc-86b1-47c3-939c-3981c0180412#tab-details

Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	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) 	C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/compose/src/nsMsgSend.cpp:4136
1 	xul.dll 	nsMsgCompose::SendMsgToServer(int, nsIMsgIdentity*, char const*) 	C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/compose/src/nsMsgCompose.cpp:1238
2 	xul.dll 	nsMsgCompose::SendMsg(int, nsIMsgIdentity*, char const*, nsIMsgWindow*, nsIMsgProgress*) 	C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/compose/src/nsMsgCompose.cpp:1458
3 	xul.dll 	XPTC__InvokebyIndex 	xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_64.asm:97
4 		@0xadffffffff 	
5 	xul.dll 	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 	js/xpconnect/src/XPCWrappedNative.cpp:1234
6 	xul.dll 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:913
7 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:467
8 	xul.dll 	static bool Interpret(struct JSContext*, class js::RunState& const) 	js/src/vm/Interpreter.cpp:2982
9 	xul.dll 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp:417
10 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:489
11 	xul.dll 	js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) 	js/src/vm/Interpreter.cpp:535
12 	xul.dll 	JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) 	js/src/jsapi.cpp:2952
13 	xul.dll 	nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*) 	js/xpconnect/src/XPCWrappedJSClass.cpp:1257
14 	xul.dll 	nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*) 	js/xpconnect/src/XPCWrappedJS.cpp:614
15 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/md/win32/xptcstubs_x86_64.cpp:174
16 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/md/win32/xptcstubs_asm_x86_64.asm:57
17 	xul.dll 	XPTC__InvokebyIndex 	xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_64.asm:97
18 		@0x232f1a0907f 	
19 	xul.dll 	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 	js/xpconnect/src/XPCWrappedNative.cpp:1234
20 	xul.dll 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:913
21 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:467
22 	xul.dll 	static bool Interpret(struct JSContext*, class js::RunState& const) 	js/src/vm/Interpreter.cpp:2982
23 	xul.dll 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp:417
24 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:489
25 	xul.dll 	js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) 	js/src/vm/Interpreter.cpp:535
26 	xul.dll 	JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) 	js/src/jsapi.cpp:3011
27 	xul.dll 	mozilla::dom::EventHandlerNonNull::Call(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) 	dom/bindings/EventHandlerBinding.cpp:260
28 	xul.dll 	mozilla::dom::EventHandlerNonNull::Call<nsISupports*>(nsISupports* const&, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JSCompartment*) 	dist/include/mozilla/dom/EventHandlerBinding.h:363
29 	xul.dll 	mozilla::JSEventHandler::HandleEvent(nsIDOMEvent*) 	dom/events/JSEventHandler.cpp:215
30 	xul.dll 	mozilla::EventListenerManager::HandleEventSubType(mozilla::EventListenerManager::Listener*, nsIDOMEvent*, mozilla::dom::EventTarget*) 	dom/events/EventListenerManager.cpp:1090
31 	xul.dll 	mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent**, mozilla::dom::EventTarget*, nsEventStatus*) 	dom/events/EventListenerManager.cpp:1259
32 	xul.dll 	mozilla::EventTargetChainItem::HandleEvent(mozilla::EventChainPostVisitor&, mozilla::ELMCreationDetector&) 	dom/events/EventDispatcher.cpp:347
33 	xul.dll 	mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) 	dom/events/EventDispatcher.cpp:527
34 	xul.dll 	mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*) 	dom/events/EventDispatcher.cpp:917
35 	xul.dll 	mozilla::EventDispatcher::DispatchDOMEvent(nsISupports*, mozilla::WidgetEvent*, nsIDOMEvent*, nsPresContext*, nsEventStatus*) 	dom/events/EventDispatcher.cpp:996
36 	xul.dll 	nsINode::DispatchEvent(nsIDOMEvent*, bool*) 	dom/base/nsINode.cpp:1180
37 	xul.dll 	nsContentUtils::DispatchXULCommand(nsIContent*, bool, nsIDOMEvent*, nsIPresShell*, bool, bool, bool, bool, unsigned short) 	dom/base/nsContentUtils.cpp:6733
38 	xul.dll 	nsXULElement::DispatchXULCommand(mozilla::EventChainVisitor const&, nsTAutoStringN<char16_t, 64>&) 	dom/xul/nsXULElement.cpp:1377
39 	xul.dll 	nsXULElement::PreHandleEvent(mozilla::EventChainVisitor&) 	dom/xul/nsXULElement.cpp:1438
40 	xul.dll 	mozilla::EventTargetChainItem::PreHandleEvent(mozilla::EventChainVisitor&) 	dom/events/EventDispatcher.cpp:445
41 	xul.dll 	mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*) 	dom/events/EventDispatcher.cpp:843
42 	xul.dll 	mozilla::EventDispatcher::DispatchDOMEvent(nsISupports*, mozilla::WidgetEvent*, nsIDOMEvent*, nsPresContext*, nsEventStatus*) 	dom/events/EventDispatcher.cpp:996
43 	xul.dll 	mozilla::PresShell::HandleDOMEventWithTarget(nsIContent*, nsIDOMEvent*, nsEventStatus*) 	layout/base/PresShell.cpp:8021
44 	xul.dll 	nsContentUtils::DispatchXULCommand(nsIContent*, bool, nsIDOMEvent*, nsIPresShell*, bool, bool, bool, bool, unsigned short) 	dom/base/nsContentUtils.cpp:6727
45 	xul.dll 	nsButtonBoxFrame::DoMouseClick(mozilla::WidgetGUIEvent*, bool) 	layout/xul/nsButtonBoxFrame.cpp:232
46 	xul.dll 	nsButtonBoxFrame::HandleEvent(nsPresContext*, mozilla::WidgetGUIEvent*, nsEventStatus*) 	layout/xul/nsButtonBoxFrame.cpp:173
47 	xul.dll 	nsPresShellEventCB::HandleEvent(mozilla::EventChainPostVisitor&) 	layout/base/PresShell.cpp:518
48 	xul.dll 	mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) 	dom/events/EventDispatcher.cpp:582
49 	xul.dll 	mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*) 	dom/events/EventDispatcher.cpp:917
50 	xul.dll 	mozilla::PresShell::DispatchEventToDOM(mozilla::WidgetEvent*, nsEventStatus*, nsPresShellEventCB*) 	layout/base/PresShell.cpp:7887
51 	xul.dll 	mozilla::PresShell::HandleEventInternal(mozilla::WidgetEvent*, nsEventStatus*, bool) 	layout/base/PresShell.cpp:7681
52 	xul.dll 	mozilla::PresShell::HandleEventWithTarget(mozilla::WidgetEvent*, nsIFrame*, nsIContent*, nsEventStatus*, bool, nsIContent**) 	layout/base/PresShell.cpp:7468
53 	xul.dll 	mozilla::EventStateManager::InitAndDispatchClickEvent(mozilla::WidgetMouseEvent*, nsEventStatus*, mozilla::EventMessage, nsIPresShell*, nsIContent*, AutoWeakFrame, bool) 	dom/events/EventStateManager.cpp:4893
54 	xul.dll 	mozilla::EventStateManager::CheckForAndDispatchClick(mozilla::WidgetMouseEvent*, nsEventStatus*) 	dom/events/EventStateManager.cpp:4935
55 	xul.dll 	mozilla::EventStateManager::PostHandleEvent(nsPresContext*, mozilla::WidgetEvent*, nsIFrame*, nsEventStatus*) 	dom/events/EventStateManager.cpp:3325
56 	xul.dll 	mozilla::PresShell::HandleEventInternal(mozilla::WidgetEvent*, nsEventStatus*, bool) 	layout/base/PresShell.cpp:7701
57 	xul.dll 	mozilla::PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*) 	layout/base/PresShell.cpp:7296
58 	xul.dll 	nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) 	view/nsViewManager.cpp:812
59 	xul.dll 	nsView::HandleEvent(mozilla::WidgetGUIEvent*, bool) 	view/nsView.cpp:1139
60 	xul.dll 	nsWindow::DispatchEvent(mozilla::WidgetGUIEvent*, nsEventStatus&) 	widget/windows/nsWindow.cpp:4186
61 	xul.dll 	nsBaseWidget::DispatchInputEvent(mozilla::WidgetInputEvent*) 	widget/nsBaseWidget.cpp:1238
62 	xul.dll 	nsWindow::DispatchMouseEvent(mozilla::EventMessage, unsigned __int64, __int64, bool, short, unsigned short, WinPointerInfo*) 	widget/windows/nsWindow.cpp:4661
63 	xul.dll 	nsWindow::ProcessMessage(unsigned int, unsigned __int64&, __int64&, __int64*) 	widget/windows/nsWindow.cpp:5620
64 	xul.dll 	nsWindow::WindowProcInternal(HWND__*, unsigned int, unsigned __int64, __int64) 	widget/windows/nsWindow.cpp:5013
65 	xul.dll 	CallWindowProcCrashProtected 	xpcom/base/nsCrashOnException.cpp:32
66 	xul.dll 	nsWindow::WindowProc(HWND__*, unsigned int, unsigned __int64, __int64) 	widget/windows/nsWindow.cpp:4965
67 	user32.dll 	UserCallWinProcCheckWow(_ACTIVATION_CONTEXT*, __int64 (*)(tagWND*, unsigned int, unsigned __int64, __int64), HWND__*, _WM_VALUE, unsigned __int64, __int64, void*, int) 	
68 	user32.dll 	DispatchMessageWorker 	
69 	xul.dll 	nsAppShell::ProcessNextNativeEvent(bool) 	widget/windows/nsAppShell.cpp:537
70 	xul.dll 	nsBaseAppShell::DoProcessNextNativeEvent(bool) 	widget/nsBaseAppShell.cpp:139
71 	xul.dll 	nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) 	widget/nsBaseAppShell.cpp:290
72 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:984
73 	xul.dll 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/threads/nsThreadUtils.cpp:517
74 	xul.dll 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:125
75 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:319
76 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc:299
77 	xul.dll 	nsBaseAppShell::Run() 	widget/nsBaseAppShell.cpp:157
78 	xul.dll 	nsAppShell::Run() 	widget/windows/nsAppShell.cpp:401
79 	xul.dll 	nsAppStartup::Run() 	toolkit/components/startup/nsAppStartup.cpp:290
80 	xul.dll 	XREMain::XRE_mainRun() 	toolkit/xre/nsAppRunner.cpp:4766
81 	xul.dll 	XREMain::XRE_main(int, char** const, mozilla::BootstrapConfig const&) 	toolkit/xre/nsAppRunner.cpp:4911
82 	xul.dll 	XRE_main(int, char** const, mozilla::BootstrapConfig const&) 	toolkit/xre/nsAppRunner.cpp:5003
83 	thunderbird.exe 	static int do_main(int, char**, char**) 	C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mail/app/nsMailApp.cpp:232
84 	thunderbird.exe 	NS_internal_main(int, char**, char**) 	C:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mail/app/nsMailApp.cpp:306
85 	thunderbird.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:129
86 	thunderbird.exe 	static int __scrt_common_main_seh() 	f:/dd/vctools/crt/vcstartup/src/startup/exe_common.inl:283
87 	kernel32.dll 	BaseThreadInitThunk 	
88 	ntdll.dll 	RtlUserThreadStart
(In reply to Patrick Brunschwig from comment #34)
> Can we backport this to TB 60? It seems that bug is quite frequent if
> Enigmail is used (no idea why).

(circling back) I have no new info so I think there is nothing to be gained in waiting and we should just take it on beta
Flags: needinfo?(jorgk)
Comment on attachment 8960365 [details] [diff] [review]
556355-fix-crash.patch

Fell off the radar, I'll get it uplifted. No harm in this patch.

But comment #40 says that it's still crashing, no?
Flags: needinfo?(jorgk)
Attachment #8960365 - Flags: approval-comm-beta+
> But comment #40 says that it's still crashing, no?
yes, no doubt further work will be needed.  the patch is at least a start.
Flags: needinfo?(Robert_Hartmann)
(In reply to Robert Hartmann from comment #40)
> (In reply to Wayne Mery (:wsmwk) from comment #38)
> > In bp-709e9c48-3c58-4ae3-9fe1-064d20180323 Robert writes "Cancel sending a
> > mail before Pinentry GUI shows . Cancel Passwort input in Pinentry"
> > 
> > So if Robert has solid steps to reproduce and is willing to try a nightly
> > build on a 64bit machine then
> > https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/
> > thunderbird-61.0a1.en-US.win64.installer.exe should have the patch.  Or
> > there is a more convulted way to get more recent nightly build from
> > https://treeherder.mozilla.org/#/jobs?repo=comm-
> > central&selectedJob=170773605 - find "artifact uploaded:
> > target.installer.exe" and download it.
> 
> Reproducible same way "Cancel sending a mail before Pinentry GUI shows .
> Cancel Passwort input in Pinentry"
> 
> Win10 64bit, TB daily, Enigmal Nightly, TB-Masterpasswort active:
> 
> IMAP-Account + Enter Masterpassword
> Write Email (to own adress)
> choose encrypt + signed (OpenPGP)
> press "send"
> press "cancel"-Button in sending-Messagebox
> After Pinentry-Window opens, press cancel there 
> 
> Thunderbird 61.0a1 Crash Report [@ nsMsgComposeAndSend::CreateAndSendMessage
> ]
> 
> Extensions
> Name 	Version 	Enabled 	ID
> Enigmail	2.1a1pre	true	{847b3a00-7ab1-11d4-8f02-006008948af5}
> Lightning	6.3a1	false	{e2fda1a4-762b-4020-b5ad-a41df1933103}
> 
> bp-bca955cc-86b1-47c3-939c-3981c0180412
> 
> https://crash-stats.mozilla.com/report/index/bca955cc-86b1-47c3-939c-
> 3981c0180412#tab-details


The crash happens here:
  if (NS_FAILED(rv) && mSendReport)
    mSendReport->SetError(nsIMsgSendReport::process_Current, rv, false);


What happens is this: if the the user cancels the pinentry dialog, then Enigmail needs to tell Thunderbird to stop sending the message. It does that by throwing an error, because AFAICT there is no other way to cancel the process from with the crypto-functions.

But at this point, the sending was already canceled, and setError was probably already executed at this point.
What exactly do you think is crashing here? We check 'mSendReport' and SetError() doesn't do much:
NS_IMETHODIMP nsMsgProcessReport::SetError(nsresult aError)
{
  mError = aError;
  return NS_OK;
}

How about adding
  nsCOMPtr<nsIMsgSend> kungFuDeathGrip(this);
to that function as well?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Patrick, if you can reproduce the crash, could you try that? If we do it soon, we can uplift that to beta 3 today.
Flags: needinfo?(patrick)
I was just reading comment #40 (by Robert Hartmann) and the crash report linked below. I didn't try to reproduce it, and I'm afraid but I can't currently do it -- my notebook is broken. 

But I think the scenario described is plausible.

Steps to reproduce: 
IMAP-Account + Enter Masterpassword
Write Email (to own adress)
choose encrypt + signed (OpenPGP)
press "send"
press "cancel"-Button in sending-Messagebox
After Pinentry-Window opens, press cancel there 

Thunderbird 61.0a1 Crash Report [@ nsMsgComposeAndSend::CreateAndSendMessage ]

https://crash-stats.mozilla.com/report/index/bca955cc-86b1-47c3-939c-3981c0180412#tab-details


It may very well be that adding 

  nsCOMPtr<nsIMsgSend> kungFuDeathGrip(this); 

is a good idea - but it would need to be in CreateAndSendMessage().
Flags: needinfo?(patrick)
(In reply to Patrick Brunschwig from comment #47)
> is a good idea - but it would need to be in CreateAndSendMessage().
That's what I meant, the function where the crash happens.
Attached patch 556355-fup.patchSplinter Review
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/47cdf1038efd
Make sure the nsIMsgSend doesn't go away before we're done (take 2). r=me DONTBUILD
Status: REOPENED → RESOLVED
Closed: Last yearLast year
Resolution: --- → FIXED
Worth a try, I'll uplift both.
You need to log in before you can comment on or make changes to this bug.