208300 - Crash sending mail - intermittent

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect)

Description

[selmer (gone)]

6/3 05 trunk build

I have crashed several times hitting the send button in the compose window.  I
don't know what the common thread is, but this last time I used file|send-link
to create the compose window.

Talkback is also crashing, so I'm not sure whether the report got sent.

Comment 1

[Matthias Versen [:Matti]]

Do you sent a talkback report for the Talkback crash ? :-)

Comment 2

[(not reading, please use [e-mail] instead)]

gotten a few reports about this, both trunk and branch.

ninoschka, david and I haven't been able to reproduce yet, but jst, bclary have.

Comment 3

[(not reading, please use [e-mail] instead)]

from nbaca:

"Cavin was crashing with yesterday's trunk build (2003-06-04) on Win2k.  
Here are his stack traces from yesterday (6/4/2003).

ntdll.dll + 0x5c41 (0x77f85c41)   	 
ntdll.dll + 0x5bd1 (0x77f85bd1) 

Today he has been running the same build, using the same profile and it hasn't
crashed." 
	 
these are like other talkbacks I've seen from jst / jrgm

Comment 4

[David :Bienvenu]

*** Bug 208562 has been marked as a duplicate of this bug. ***

Comment 5

[Rafael Ebron (:rebron)]

I don't believe the crash happens when sending mail, as mail is actually sent. 
I believe the crash happens when copying to the sent mail folder.  Testing now.

Comment 6

[David :Bienvenu]

yes, that's the general consensus; it happens right when we start copying to the
online imap sent folder.

Comment 7

[Samir Gehani]

adt: nsbeta1+/adt1

Comment 8

[Johnny Stenback (:jst)]

Here's a stacktrace from an optimized with symbols build. I haven't been able to
reporduce this crash in a debug build yet :-(

 	NTDLL.DLL!RtlpWaitForCriticalSection()  + 0x60
 	NTDLL.DLL!RtlIntegerToUnicodeString()  + 0x51
>	necko.dll!nsSocketTransport::OnSocketEvent(unsigned int type=87306748,
unsigned int uparam=6, void * vparam=0x00000000)  Line 1172
 	necko.dll!nsSocketTransportService::ServiceEventQ()  Line 350
 	necko.dll!nsSocketTransportService::Run()  Line 660 + 0x7
 	xpcom.dll!nsThread::Main(void * arg=0x00e22598)  Line 134
 	nspr4.dll!_PR_NativeRunThread(void * arg=0x00df0da0)  Line 455
 	msvcrt.dll!_beginthreadex()  + 0xb2

Comment 9

[Johnny Stenback (:jst)]

So I was able to run a branch build in purify and I was able to send email to
see if I'd see anything interesting, but nothing out of the ordinary :-(

Comment 10

[(not reading, please use [e-mail] instead)]

asa, this is bad enough to block 1.4

given the stack trace, cc'ing our socket transport guru, darin.

Comment 11

[David :Bienvenu]

I've reproduced a crash sending mail, by doing a release build with symbols, 
and turning on SSL. Here's the stack trace:

nsSocketTransportService::PostEvent(nsSocketTransportService * const 
0x011fbdd8, nsISocketEventHandler * 0x040f26fc, unsigned int 0x00000006, 
unsigned int 0x00000000, void * 0x00000000) line 114 + 23 bytes
nsSocketTransport::OnOutputPending(nsSocketTransport * const 0x00000014) line 
297 + 29 bytes
nsSocketOutputStream::AsyncWait(nsSocketOutputStream * const 0x040f277c, 
nsIOutputStreamNotify * 0x037f548c, unsigned int 0x00000000, nsIEventQueue * 
0x00000000) line 592
nsStreamCopierIB::OnInputStreamReady(nsStreamCopierIB * const 0x037f5488, 
nsIAsyncInputStream * 0x037f5280) line 297
nsPipeEvents::~nsPipeEvents(nsPipeEvents * const 0x00000014) line 559
nsPipeOutputStream::CloseEx(nsPipeOutputStream * const 0x037f52a4, unsigned int 
0x804b0002) line 1009
nsMsgAsyncWriteProtocol::CloseSocket(nsMsgAsyncWriteProtocol * const 
0x00000014) line 1310
nsSmtpProtocol::ProcessProtocolState(nsSmtpProtocol * const 0x00000014, nsIURI 
* 0x040f1f9c, nsIInputStream * 0x040f1f9c, unsigned int 0x00000163, unsigned 
int 0x00000034) line 1585 + 8 bytes
nsMsgProtocol::OnDataAvailable(nsMsgProtocol * const 0x040f2428, nsIRequest * 
0x037f5938, nsISupports * 0x040f1f9c, nsIInputStream * 0x037f56b0, unsigned int 
0x00000163, unsigned int 0x00000034) line 326 + 20 bytes
nsInputStreamPump::OnStateTransfer(nsInputStreamPump * const 0x00000014) line 
418 + 24 bytes
nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x037f593c, 
nsIAsyncInputStream * 0x037f56b0) line 322
nsInputStreamReadyEvent::EventHandler(PLEvent * 0x046f289c) line 117
PL_HandleEvent(PLEvent * 0x046f289c) line 672
PL_ProcessPendingEvents(PLEventQueue * 0x1002bee6) line 606 + 6 bytes
_md_EventReceiverProc(HWND__ * 0x0222d7a8, unsigned int 0x00401ee8, unsigned 
int 0x0124edb0, long 0x80000000) line 1411

we're crashing because, in nsSocketOutputStream::AsyncWait
mTransport has been deleted. I'm trying purify now.

Comment 12

[David :Bienvenu]

Attachment: proposed fix

I think the fix is to close the output stream before closing the socket - I'll
run with this a while and see.

Comment 13

[David :Bienvenu]

fix checked in, r/sr=sspitzer over aim - people will have to try tomorrow's
build and see if they still have this problem, and we'll have to look at
talkback reports. Purify was not helpful, I think because this bug is difficult
to reproduce - it usually takes me about 10 message sends to make this crash. I
have not seen this crash with the patch applied, but it is intermittent. I'm not
sure why talkback's stack traces are so useless in this case. It's possible that
there's some other problem out there, but I think there's a good chance this was
the problem.

Comment 14

[(not reading, please use [e-mail] instead)]

Comment on attachment 125169 [details] [diff] [review]
proposed fix

r/sr=sspitzer

if this fixes it, we want this on 1.4

Comment 15

[Frank_Vance]

I believe I have seen this with Build 2003050714 (1.4b) on Windows 2000.  Try
Talkback numbers TB20814492K  TB20814458M and TB20814409X

Comment 16

[selmer (gone)]

Does any of this explain why talkback also crashes when I hit this?

Comment 17

[David :Bienvenu]

I don't know - it seems like for many people, talkback reports are getting
through for this bug. A couple possibilities - talkback is somehow hosed on your
machine (if other talkback reports are getting through, then that's out). The
other possibility is that somehow we're completely hosing something that
talkback uses, at least on your machine. Not very helpful, I'm afraid.

To Rafael, the crash I saw happens at the very end of the message send, when
we're trying to clean up the smtp connection, so it's after the message has been
sent.

Comment 18

[Cavin Song]

Yeah, the msgs were sent ok (not 100% sure since I always sent another one) when
the program crashed.

Comment 19

[(not reading, please use [e-mail] instead)]

fix landed on the 1.4 branch and the trunk.

Comment 20

[(not reading, please use [e-mail] instead)]

Comment on attachment 125169 [details] [diff] [review]
proposed fix

a=sspitzer,asa

Comment 21

[Darin Fisher]

bienvenu: was this a regression from some recent bug fix or do the crashes go
all the way back to the async-io landing (in mid-january)?

Comment 22

[David :Bienvenu]

Darin, I don't know. I haven't seen any likely culprits in the suspected
starting point of this bug (early May). Querying talkback for crashes in ntdll
produces a firehose of data. My suspicion is that the async io landing left this
bug lurking in the background and some otherwise innocuous change exposed it. 

Comment 23

[Darin Fisher]

ok, incidentally i just hit this crash today with the 6/9 build... at least i
think it's this crash though the stack only listed ntdll twice :-(
i'll start using tomorrows build as soon as it's available.

Comment 24

[Darin Fisher]

btw, i was running a branch build when i hit the crash.

Comment 25

[esther]

Ninoschka was able to reproduce this on her win2000 system, I have not been able
to reproduce it on my winxp system.  reassigning qa to nbaca for verification.

Comment 26

[Johnny Stenback (:jst)]

I used yesterdays trunk build all day w/o crashing when sending email. That's
been very unusual lately with builds before yesterdays build, so it looks like
this is fixed! Way to go bienvenu!

Comment 27

[selmer (gone)]

I agree with jst, looks good so far!  

Comment 28

[Cavin Song]

It's been working well for me for a day now. Thanks David.

Comment 29

[David :Bienvenu]

no problem, I'm glad it's working for everyone.

Comment 30

[Ninoschka Baca]

Trunk build 2003-06-09: Win2k - ok.
Branch build 2003-06-10: Win2k - ok.
Verified Fixed.

Using the 6/9 branch build I crashed fairly frequently. With the 6/10 branch
build I have not experienced a crash and I have used this build since this morning.