Note: There are a few cases of duplicates in user autocompletion which are being worked on.

crash [@ nsMsgAttachmentHandler::GetMimeDeliveryState(nsIMsgSend**)]

VERIFIED FIXED in Thunderbird 24.0


MailNews Core
7 years ago
4 years ago


(Reporter: wsmwk, Assigned: hiro)


({crash, topcrash})

Thunderbird 24.0
crash, topcrash

Thunderbird Tracking Flags

(thunderbird-esr17- wontfix)


(crash signature)


(1 attachment, 2 obsolete attachments)

crash [@ nsMsgAttachmentHandler::GetMimeDeliveryState(nsIMsgSend**)]

0	thunderbird.exe	nsMsgAttachmentHandler::GetMimeDeliveryState	mailnews/compose/src/nsMsgAttachmentHandler.cpp:1347
1	thunderbird.exe	nsURLFetcher::OnStartRequest	mailnews/compose/src/nsURLFetcher.cpp:257
2	thunderbird.exe	nsDocumentOpenInfo::OnStartRequest	uriloader/base/nsURILoader.cpp:290
3	thunderbird.exe	nsHttpChannel::CallOnStartRequest	netwerk/protocol/http/src/nsHttpChannel.cpp:848
4	thunderbird.exe	nsHttpChannel::ProcessNormal	netwerk/protocol/http/src/nsHttpChannel.cpp:1155
5	thunderbird.exe	nsHttpChannel::ProcessResponse	netwerk/protocol/http/src/nsHttpChannel.cpp:1024
6	thunderbird.exe	nsHttpChannel::OnStartRequest	netwerk/protocol/http/src/nsHttpChannel.cpp:5190
7	thunderbird.exe	nsInputStreamPump::OnStateStart	netwerk/base/src/nsInputStreamPump.cpp:441
8	thunderbird.exe	nsInputStreamPump::OnInputStreamReady	netwerk/base/src/nsInputStreamPump.cpp:397


7 years ago
OS: Windows Vista → All
Crash Signature: [@ nsMsgAttachmentHandler::GetMimeDeliveryState(nsIMsgSend**)]
#1 mime-related crash
~90 ranked crash for version 13.0.1

bp-994e32c1-f405-4887-9417-a898b2120621 version 13.0.1
bp-8b55941e-8c02-4b78-9ff7-087342120601 Mac v12.0.1 (pzampino)
Crash Signature: [@ nsMsgAttachmentHandler::GetMimeDeliveryState(nsIMsgSend**)] → [@ nsMsgAttachmentHandler::GetMimeDeliveryState(nsIMsgSend**)] [@ nsMsgAttachmentHandler::GetMimeDeliveryState ]
Version: 1.9.2 Branch → Trunk
increased to ~ #60 for version 17.

The root cause may be that nsMsgAttachmentHandler isn't refcount based object.  Since nsIURLFetcher is async, there is no way whether deleted.
(In reply to Makoto Kato from comment #3)
> The root cause may be that nsMsgAttachmentHandler isn't refcount based
> object.  Since nsIURLFetcher is async, there is no way whether deleted.

thanks Makoto

possible testcase - / bp-5df7b9b5-021b-4983-aec2-d7ded2130527 - describes where the a file for the user's signature is accessible because the network folder is gone.  bp-3fd191cd-77dd-4a84-83b0-a0ae52130525 adds more flavor about the UI behavior "TB keeps putting a warning on the screen telling me I can't save this email (another reply) as a draft".  (I've not been able to reproduce using daily build and 17.0.6, but perhaps someone else can)

side note - it seems for many months (perhaps even a year or more) I/we've missed identifying nsMsgAttachmentHandler::GetMimeDeliveryState(nsIMsgSend**) as a topcrash, perhaps because I typically check bugs against rankings via signature rather than bug number. Another example where bug 518823 would have helped avoid this problem.
Crash Signature: [@ nsMsgAttachmentHandler::GetMimeDeliveryState(nsIMsgSend**)] [@ nsMsgAttachmentHandler::GetMimeDeliveryState ] → [@ nsMsgAttachmentHandler::GetMimeDeliveryState(nsIMsgSend**)] [@ nsMsgAttachmentHandler::GetMimeDeliveryState ] [@ @0x0 | nsDocumentOpenInfo::OnStartRequest(nsIRequest*, nsISupports*)]
Keywords: topcrash
potential testers if we need them:

Comment 6

4 years ago
Created attachment 759531 [details] [diff] [review]
Make nsMsgAttachmentHandler ref-countable

To make nsMsgAttachmentHandler ref-countable class nsIMsgSend.getAttachmentHandlers have to be changed. Fortunately nsIMsgSend.getAttachmentHandlers is not scriptable and used only in mailnews core. I hope there is no extension using nsIMsgSend.getAttachmentHandlers.

nsIMsgSend.attachmentCount is not used any more in Thunderbird codes but left there because it's scriptable.
Assignee: nobody → hiikezoe
Attachment #759531 - Flags: review?(m_kato)

Comment 7

4 years ago
Created attachment 759586 [details] [diff] [review]
Make nsMsgAttachmentHandler ref-countable rev.2

I had totally forgotten to fix nsURLFetcher.cpp in the previous patch.
Attachment #759531 - Attachment is obsolete: true
Attachment #759531 - Flags: review?(m_kato)
Attachment #759586 - Flags: review?(m_kato)
Comment on attachment 759586 [details] [diff] [review]
Make nsMsgAttachmentHandler ref-countable rev.2

Review of attachment 759586 [details] [diff] [review]:

::: mailnews/compose/src/nsMsgSend.cpp
@@ +1926,3 @@
>      {
>        nsString   newSpec(NS_LITERAL_STRING("cid:"));
> +      newSpec.Append(NS_ConvertASCIItoUTF16(m_attachments[duplicateOf == -1 ? i : duplicateOf]->m_contentId));

Use newSpec.AppendASCII(...)

@@ +2111,5 @@
>            // We'd like to output a part for the attachment, just an html part
>            // with information about how to download the attachment.
> +          // m_attachments[newLoc]->m_done = true;
> +          attachment->GetHtmlAnnotation(m_attachments[newLoc]->mHtmlAnnotation);
> +          m_attachments[newLoc]->m_type = "text/html";

Use m_attachments[newLoc]-m_type.AssignLiteral(...);
Attachment #759586 - Flags: review?(m_kato) → review+

Comment 9

4 years ago
Created attachment 763216 [details] [diff] [review]
Make nsMsgAttachmentHandler ref-countable rev.3

Carrying over review+
Attachment #759586 - Attachment is obsolete: true
Attachment #763216 - Flags: review+
Keywords: checkin-needed
Last Resolved: 4 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 24.0

Comment 11

4 years ago
It's #11 top crasher in TB 17.0.6 and #8 in 17.0.7.
status-thunderbird-esr17: --- → affected
tracking-thunderbird-esr17: --- → ?
I'd semi-like to take this, but the changes are too substantial for a branch. Given the closeness of TB 24, I think we can just let this ride the trains and ship it in 24.
status-thunderbird-esr17: affected → wontfix
tracking-thunderbird-esr17: ? → -
Thanks Hiro

Signature gone in T24 and newer
Depends on: 939391
You need to log in before you can comment on or make changes to this bug.