Closed Bug 531262 Opened 10 years ago Closed 9 years ago

crash involving saving a message with an attachment as a draft [@ nsMsgAttachmentHandler::Abort()]


(MailNews Core :: Composition, defect, critical)

1.9.1 Branch
Not set


(blocking-thunderbird5.0 needed, blocking-thunderbird3.1 needed, thunderbird3.1 .11-fixed)

Thunderbird 5.0b1
Tracking Status
blocking-thunderbird5.0 --- needed
blocking-thunderbird3.1 --- needed
thunderbird3.1 --- .11-fixed


(Reporter: tibor.weigand, Unassigned)


(Blocks 1 open bug)


(5 keywords, Whiteboard: [has patch for review][ccbr][STRs comment 14 - dubious])

Crash Data


(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20091102 Firefox/3.5.5 GTB5 (.NET CLR 3.5.30729)
Build Identifier: Thunderbird 3.0 rc1

After a crash which happened when I left new mail opened and problem by automatic saving occurred I sent crash report. I restart Thunderbird and it was completely reset! It means installed add-ons, received mails, accounts etc. disappeared completely!

Reproducible: Didn't try

(Crash report sent!)
Can you give us the crashid ( ?
Keywords: crash
Of course:

(In reply to comment #1)
> Can you give us the crashid ( ?
Signature	nsMsgAttachmentHandler::Abort()
UUID	a6d9382a-0849-403a-9ea9-d7bd32091126
Time 	2009-11-26 05:09:04.611101
Uptime	2506
Product	Thunderbird
Version	3.0
Build ID	20091121183158
Branch	1.9.1
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	GenuineIntel family 15 model 4 stepping 9
Crash Address	0x1a3f5a8
User Comments	New mail left unsent for few minutes, problem occured by automatic saving as draft.
Processor Notes 	
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 		@0x1a3f5a8 	
1 	thunderbird.exe 	nsMsgAttachmentHandler::Abort 	mailnews/compose/src/nsMsgAttachmentHandler.cpp:1052
2 	thunderbird.exe 	nsMsgComposeAndSend::Abort 	mailnews/compose/src/nsMsgSend.cpp:4981
3 	thunderbird.exe 	nsMsgComposeAndSend::Fail 	mailnews/compose/src/nsMsgSend.cpp:3831
4 	thunderbird.exe 	nsMsgAttachmentHandler::UrlExit 	mailnews/compose/src/nsMsgAttachmentHandler.cpp:1164
5 	thunderbird.exe 	FetcherURLDoneCallback 	mailnews/compose/src/nsMsgAttachmentHandler.cpp:534
6 	thunderbird.exe 	nsURLFetcher::OnStopRequest 	mailnews/compose/src/nsURLFetcher.cpp:327
7 	thunderbird.exe 	nsURLFetcher::OnStateChange 	mailnews/compose/src/nsURLFetcher.cpp:415
8 	thunderbird.exe 	nsDocLoader::FireOnStateChange 	uriloader/base/nsDocLoader.cpp:1259
9 	thunderbird.exe 	nsDocLoader::doStopURLLoad 	uriloader/base/nsDocLoader.cpp:856
10 	thunderbird.exe 	nsDocLoader::OnStopRequest 	uriloader/base/nsDocLoader.cpp:669
11 	thunderbird.exe 	nsLoadGroup::RemoveRequest 	netwerk/base/src/nsLoadGroup.cpp:688
12 	thunderbird.exe 	nsHttpChannel::HandleAsyncReplaceWithProxy 	netwerk/protocol/http/src/nsHttpChannel.cpp:1241
13 	thunderbird.exe 	nsHttpChannel::OnProxyAvailable 	netwerk/protocol/http/src/nsHttpChannel.cpp:4793
14 	thunderbird.exe 	nsAsyncResolveRequest::DoCallback 	netwerk/base/src/nsProtocolProxyService.cpp:187
15 	thunderbird.exe 	nsAsyncResolveRequest::OnQueryComplete 	netwerk/base/src/nsProtocolProxyService.cpp:168
16 	thunderbird.exe 	PendingPACQuery::Complete 	netwerk/base/src/nsPACMan.cpp:137
17 	thunderbird.exe 	nsPACMan::ProcessPendingQ 	netwerk/base/src/nsPACMan.cpp:386
18 	thunderbird.exe 	nsPACMan::OnStreamComplete 	netwerk/base/src/nsPACMan.cpp:454
19 	thunderbird.exe 	nsStreamLoader::OnStopRequest 	netwerk/base/src/nsStreamLoader.cpp:108
20 	thunderbird.exe 	nsHttpChannel::OnStopRequest 	netwerk/protocol/http/src/nsHttpChannel.cpp:4967
21 	thunderbird.exe 	nsInputStreamPump::OnStateStop 	netwerk/base/src/nsInputStreamPump.cpp:576
22 	thunderbird.exe 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:401
23 	xpcom_core.dll 	nsOutputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:111
24 	xpcom_core.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:521
25 	xpcom_core.dll 	NS_ProcessNextEvent_P 	objdir-tb/mozilla/xpcom/build/nsThreadUtils.cpp:236
26 	thunderbird.exe 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
27 	thunderbird.exe 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:193
28 	thunderbird.exe 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3321
29 	thunderbird.exe 	NS_internal_main 	mail/app/nsMailApp.cpp:103
30 	thunderbird.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:110
31 	thunderbird.exe 	__tmainCRTStartup 	objdir-tb/mozilla/memory/jemalloc/src/crtexe.c:591
32 	kernel32.dll 	BaseProcessStart
Component: General → Message Compose Window
QA Contact: general → message-compose
Summary: Profile reset after crash → crash involving saving a message with an attachment as a draft [@ nsMsgAttachmentHandler::Abort]
#30 for thunderbird  3.0  (but still early for this to be a good long term number)
not a new crash - goes back to at least 3.0b1

bp-a8afd755-f515-4012-95c7-82f182090924 	3.0pre
Trying to forward an email as attachment. Nothing out of the ordinary.

Trying to add an image file (linked from google site) to a local template.
Ever confirmed: true
Summary: crash involving saving a message with an attachment as a draft [@ nsMsgAttachmentHandler::Abort] → crash involving saving a message with an attachment as a draft [@ nsMsgAttachmentHandler::Abort()]
The same seems to have happened in Linux as well (Mozilla/5.0 (X11; U; Linux i686; nl; rv: Gecko/20091130 SUSE/3.0.0-1.1.1 Thunderbird/3.0).
Whilst typing a reply-message to which I had attached a file of 200kB, thunderbird generated the bugreport and closed down. On restart I found that I did have a saved concept, although it was from a couple of minutes before the crash. I did not save it by hand, it must have saved automatically.
I have not lost any setting as far as I can see.
O/S used is openSUSE 11.2 with Gnome Desktop.
No crash visible post 3.0.1 !
Whiteboard: [revisit a week after 3.0.2]
still appearing in v3.0.3. But it has fallen to #71, from #13 in v3.0.1
bp-cdf0846e-dcf6-4e72-8c3c-3429a2100311 Mac
OS: Windows XP → All
Whiteboard: [revisit a week after 3.0.2]
PMed 3 crash reporters.
#46 crash currently for v3.0.3, so apparently ranking fluctuates quite a bit.

13 most common crashes with "Attach*" in stack (of which this bug is the most frequent) - I guess more bug reports are needed.
nsMsgComposeAndSend::Fail(unsigned int, unsigned short const*, unsigned int*)
mime_encode_qp_buffer(MimeEncoderData*, char const*, int)
nsQueryInterfaceWithError::operator()(nsID const&, void**)
strlen | nsDependentCString::nsDependentCString(char const*)
@0x0 | nsMsgComposeAndSend::Fail(unsigned int, unsigned short const*, unsigned int*)
XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, nsWrapperCache*, int, XPCWrappedNative**)
nsMsgSendReport::DisplayReport(nsIPrompt*, int, int, unsigned int*)
nsQueryInterfaceWithError::operator()(nsID const&, void**) const
crashed today, bp-b3d04068-1331-497d-b59d-f31962100617 using the steps in bug 204250. If I didn't crash in bug 204250  I would guess this is a regression in v.3

attempted to reproduce once, but the message sent and no crash
1. Create a new message
2. Select File|Attach and enter ""
3. Send the message

current ranking #55 in 3.0.4. emailed
bp-f3abd492-7d8c-49b0-adc0-0797c2100527 (paul)
bp-3c425dd7-8973-4ffc-b213-a351e2100605 (dave)
Keywords: regression
goes back as far as 3.0a1 2008050715, so we aren't going to get a regression range
#9 crash for v3.1.1 and #11 for v3.1 => topcrash 
(but I did not skim crash reports to see if there were multiples which might discount the topcrash designation)

two crashes have email addresses if follow up is needed.
Version: unspecified → 3.0
Blocks: 204250
Tibor, can you still reproduce this issue? And what steps do you use?
#5 crash for 3.1.4 (get thee bug to your proper component).  So this is wanted for v3.1.

Bug 537407 is same crash stack, except this bug has nsMsgAttachmentHandler::Abort as frame 0. 537407 = crash [@ nsMsgComposeAndSend::Fail(unsigned int, unsigned short const*, unsigned int*)] and [@ @0x0 | nsMsgComposeAndSend::Fail(unsigned int, unsigned short const*, unsigned int*)] and [@ nsMsgComposeAndSend::Abort()

W. Donkers, Tibor, do you still see this crash?

bp-057c5b41-c336-445f-b6e0-871222100902 (paul)
bp-a6b2f3bb-c09f-4619-858d-3cb5d2100928 (sebas)
bp-93f87479-bea3-49f7-af23-d639c2100903 (rousseau)
bp-df80a18d-494c-48dc-ba0a-acfb52100913  (mar7t1n)
bp-503cf8e7-6f96-4f41-8c27-06b6a2100927 (jayvee) "had an email with several fotos as attachement, and one picture I dragged and dropped from a website into the email body. I think TB wanted to save the mail as draft, because I got an error message that "20234.jpg could not be saved. Still want to save", or something like that. That's the image I dragged and dropped. I hit cancel and TB crashed."
Blocks: 537407
blocking-thunderbird3.1: --- → ?
Component: Message Compose Window → Attachments
Keywords: topcrash+
Product: Thunderbird → MailNews Core
QA Contact: message-compose → attachments
Version: 3.0 → 1.9.1 Branch
(I haven't reproduced martin's steps below but they are quite detailed)

mar7t1n/martin bp-df80a18d-494c-48dc-ba0a-acfb52100913  wrote 
"I have a HTML signature line with a in it. ie a logo of my website. It's only a small file. It's shown ok when you create the email. I did have AutoSave switched on, but have now disabled it, because when TB saves as draft or indeed if you do it manually then TB tries to save the attached image as well and fails with the message: 
  There was a problem including the file [mylogo.png] in the message. 
  Would you like to continue saving the message without this file?
If you click OK it carries on. If you click CANCEL, then TB says
  Unable to save your message as draft.
  Please verify that your Mail & Newsgroups account settings are correct 
  and try again.
OK button only and when you click it that's when it crashes."

javyvee bp-503cf8e7-6f96-4f41-8c27-06b6a2100927 wrote me 
"I was running a backup which rsynced the profile (using cygwin). My guess now is that Thunderbird couldn't write the draft because the profile was flagged as read-only at that particular moment. So the error ("couldn't write draft") was correct, but the handling (crash) wasn't."
Whiteboard: steps comment 14
Thunderbird qa and dev team, we have an excellent bug report here - we should be able to squash this topcrasher.  I don't know why, but there are no trunk crashes. Can anyone reproduce this on trunk?  xref bug 537407

timeless, all crashes are

top of correlation list

96% (162/168) vs.  56% (4897/8730) midimap.dll
96% (161/168) vs.  56% (4879/8730) msacm32.drv
97% (163/168) vs.  57% (5007/8730) msacm32.dll
96% (162/168) vs.  57% (4935/8730) wdmaud.drv
52% (88/168) vs.  19% (1650/8730) avrt.dll
52% (88/168) vs.  19% (1652/8730) ksuser.dll
52% (87/168) vs.  19% (1681/8730) MMDevAPI.dll

seems odd that none of the sigs are topcrash in seamonkey
bp-aa4a0440-584e-4c37-b008-45fae2101122 is an example
blocking-thunderbird5.0: --- → ?
Whiteboard: steps comment 14 → [ccbr][STRs comment 14]
note: crashes prior to June have aged off of crash-stats

examples of recent crashes
can someone please track down a .dmp?
(In reply to comment #17)
> can someone please track down a .dmp?

Josh, you are in the right group soyou  can log in to the Socorro admin interface, then there will be links under the "Raw Dumps" section on a report/index page.

I'm not nor wayne in the right group to get the dumps ourselves.
sorry, sometimes i get lists of reports none of which have .dump's included.

basically i need the query ui to let me filter to reports which have .dump's. i've complained to people, maybe someone will fix it for me.

i've found a .dump for this one, i'll look over dinner.
timeless, any luck?

> i've found a .dump for this one, i'll look over dinner.
I don't think this would block 3.3 final, but I think given the amount of crashes we do want to put some effort into it.

I tried the first of the STRs in comment 14 and couldn't get a crash on trunk (though I doubt trunk is fixed, more that the STRs are probably incomplete).
blocking-thunderbird3.1: ? → needed
blocking-thunderbird5.0: ? → needed
Keywords: testcase-wanted
Whiteboard: [ccbr][STRs comment 14] → [ccbr][STRs comment 14 - dubious]
martin via bp-6f435c5c-fbfc-45da-96b3-5e9e62110211 describes how he reproduces this issue...

account A - never auto-delete "old" message

folder B in "Local Folders" - account settings of "Local Folders" set to "delete messages older than 'x' days"

message arrives in (a folder "martin@a1" in) account A, and account A is set to "never auto delete"

i have setup many rules that automatically move incoming message to their (according to the clients name) folders to easier locate emails and to organize

for this specific client i have not setup such a rule, yet
so i manually moved 2 or 3 emails from account A into the clients folder located in "Local Folders"
1 or 2 of those emails where older than 'x' days and because "Local Folders" was set to "delete messages older than 'x' days this 1 or 2 message(s) never showed up in the clients folder...

that happened long ago and i thought maybe i clicked something wrong or released the mousebutton on accident at the wrong position but then found out about that auto-delete setting...

that 'back then' i have changed and those email where never again affected, but i forgot to change the setting "auto delete" for "Local Folders" and i am 100% sure that this is what caused that 1 or 2 email(s) do disappear.
seth, any thoughts?

(In reply to comment #20)
> timeless, any luck?
> > i've found a .dump for this one, i'll look over dinner.

timeless, are you in need of another dump?
(reporter is no longer using thunderbird)
holding and using a weak reference to the nsIRequest in nsMsgAttachmentHandler might help here.
using a strong reference fixes the crash - I'm not seeing the attachment handler get deleted, even though I'm breaking the strong reference, which makes me think there's something more going on.
This should fix the crash. I'm reasonably sure this doesn't introduce any new cycles.
Assignee: nobody → dbienvenu
Attachment #528314 - Flags: review?(neil)
Assignee: dbienvenu → nobody
Component: Attachments → Composition
QA Contact: attachments → composition
Whiteboard: [ccbr][STRs comment 14 - dubious] → [has patch for review][ccbr][STRs comment 14 - dubious]
Comment on attachment 528314 [details] [diff] [review]
hold a ref to nsIRequest

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

::: mailnews/compose/src/nsMsgAttachmentHandler.cpp
@@ +1133,5 @@
+  nsCOMPtr<nsIRequest> saveRequest = mRequest;
+  mRequest = nsnull;

Slightly neater way of writing this:

nsCOMPtr<nsIRequest> saveRequest;
Attachment #528314 - Flags: review?(neil) → review+
fixed on trunk, using .swap.
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a4
Comment on attachment 528314 [details] [diff] [review]
hold a ref to nsIRequest

getting on 3.1.11 radar
Attachment #528314 - Flags: approval-thunderbird3.1.11?
Comment on attachment 528314 [details] [diff] [review]
hold a ref to nsIRequest

iirc we agreed this was fine to take for 3.1.11. If you agree David, please land.
Attachment #528314 - Flags: approval-thunderbird3.1.11? → approval-thunderbird3.1.11+
Crash Signature: [@ nsMsgAttachmentHandler::Abort()]
You need to log in before you can comment on or make changes to this bug.