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

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[Tibor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) 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!)

Comment 1

[Ludovic Hirlimann [:Usul]]

Can you give us the crashid (http://kb.mozillazine.org/Breakpad) ?

Comment 2

[Tibor]

Of course:
bp-a6d9382a-0849-403a-9ea9-d7bd32091126

(In reply to comment #1)
> Can you give us the crashid (http://kb.mozillazine.org/Breakpad) ?

Comment 3

[timeless]

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 Reason	EXCEPTION_ILLEGAL_INSTRUCTION
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

Comment 4

[Wayne Mery (:wsmwk)]

#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.

bp-f31318ad-47ac-4094-9fc7-39f552090627
Trying to add an image file (linked from google site) to a local template.

Comment 5

[W. Donkers]

Attachment: bugreport generated by thunderbird

The same seems to have happened in Linux as well (Mozilla/5.0 (X11; U; Linux i686; nl; rv:1.9.1.5) 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.

Comment 6

[Ludovic Hirlimann [:Usul]]

No crash visible post 3.0.1 !

Comment 7

[Wayne Mery (:wsmwk)]

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

Comment 8

[Wayne Mery (:wsmwk)]

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.
nsMsgAttachmentHandler::Abort()
nsMsgComposeAndSend::Fail(unsigned int, unsigned short const*, unsigned int*)
mime_encode_qp_buffer(MimeEncoderData*, char const*, int)
nsQueryInterfaceWithError::operator()(nsID const&, void**)
nsMsgComposeAndSend::GatherMimeAttachments()
ClassInfo2NativeSetMap::Find(nsIClassInfo*)
strlen | nsDependentCString::nsDependentCString(char const*)
@0x0 | nsMsgComposeAndSend::Fail(unsigned int, unsigned short const*, unsigned int*)
XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, nsWrapperCache*, int, XPCWrappedNative**)
nsMsgAttachmentHandler::GetMimeDeliveryState(nsIMsgSend**)
nsMsgComposeAndSend::Abort()
nsMsgSendReport::DisplayReport(nsIPrompt*, int, int, unsigned int*)
nsQueryInterfaceWithError::operator()(nsID const&, void**) const

Comment 9

[Wayne Mery (:wsmwk)]

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 "http://www.abcnews.com"
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)

Comment 10

[Wayne Mery (:wsmwk)]

goes back as far as 3.0a1 2008050715, so we aren't going to get a regression range

Comment 11

[Wayne Mery (:wsmwk)]

#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.
bp-20f43910-0c12-4d4f-aeaa-110052100723
bp-f8e64642-3ca8-461d-8172-c502a2100725

Comment 12

[Wayne Mery (:wsmwk)]

Tibor, can you still reproduce this issue? And what steps do you use?

Comment 13

[Wayne Mery (:wsmwk)]

#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."

Comment 14

[Wayne Mery (:wsmwk)]

(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."

Comment 15

[Wayne Mery (:wsmwk)]

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
EXCEPTION_ACCESS_VIOLATION_READ
0x2e

top of correlation list
EXCEPTION_ACCESS_VIOLATION_READ (168)

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

Comment 16

[Wayne Mery (:wsmwk)]

note: crashes prior to June have aged off of crash-stats

examples of recent crashes
bp-ab245248-a2f1-4434-b272-972212101113
bp-795e6623-63aa-46ad-84b6-6affa2101114 
bp-eabbfeec-6fb6-4992-af36-012c12101113

Comment 17

[timeless]

can someone please track down a .dmp?

Comment 18

[Ludovic Hirlimann [:Usul]]

(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.

Comment 19

[timeless]

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.

Comment 20

[Wayne Mery (:wsmwk)]

timeless, any luck?

> i've found a .dump for this one, i'll look over dinner.

Comment 21

[Mark Banner (:standard8)]

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).

Comment 22

[Wayne Mery (:wsmwk)]

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.

Comment 23

[Wayne Mery (:wsmwk)]

bp-09132b6f-da74-4873-aa0f-2f8052110225 (meahardy)
bp-ee864497-4edb-4b37-8234-7570b2110304 (muskyfur) with comments

Comment 24

[Wayne Mery (:wsmwk)]

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?

Comment 25

[Wayne Mery (:wsmwk)]

(reporter is no longer using thunderbird)

Comment 26

[David :Bienvenu]

holding and using a weak reference to the nsIRequest in nsMsgAttachmentHandler might help here.

Comment 27

[David :Bienvenu]

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.

Comment 28

[David :Bienvenu]

Attachment: hold a ref to nsIRequest

This should fix the crash. I'm reasonably sure this doesn't introduce any new cycles.

Comment 29

[[e-mail]]

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 @@
 nsresult
 nsMsgAttachmentHandler::Abort()
 {
+  nsCOMPtr<nsIRequest> saveRequest = mRequest;
+  mRequest = nsnull;

Slightly neater way of writing this:

nsCOMPtr<nsIRequest> saveRequest;
saveRequest.swap(mRequest);

Comment 30

[David :Bienvenu]

fixed on trunk, using .swap.

http://hg.mozilla.org/comm-central/rev/44696b7ee959

Comment 31

[David :Bienvenu]

Comment on attachment 528314 [details] [diff] [review]
hold a ref to nsIRequest

getting on 3.1.11 radar

Comment 32

[Serge Gautherie (:sgautherie)]

http://hg.mozilla.org/releases/comm-2.0/rev/cc4edc9cf504

Comment 33

[Mark Banner (:standard8)]

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.

Comment 34

[David :Bienvenu]

fixed for 3.1.11 - http://hg.mozilla.org/releases/comm-1.9.2/rev/cc2222a35d1b