14612 - Messenger freezes when Sending a Message with 8 KB attachment.

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Suresh]

Overview Description:
Messenger freezes when Sending a Message with 100 KB attachment. I found this
when doing Performance Testing. The file I attached is
/mozilla/mailnews/compose/src/nsMsgSend.cpp

Steps to Reproduce:
1. Start Messenger.
2. Bring up Compose window. Attach the 100 KB file.
3. Click Send. The compose window closes but Messenger freezes.

Build Date & Platform Bug Found:
9/21/99 and 9/22/99 Windows release build.

Comment 1

[Jean-Francois Ducarroz]

Just did the same test on my Mac with a debug build from yesterday morning and didn't have any problem! Will try on
window now...

Comment 2

[Jean-Francois Ducarroz]

I can see the hang on Window. Can somebody test on UNIX for me please?

Comment 3

[Scott MacGregor]

We're flooding the channel to the socket (which can only hold 32KB of data) (it
used to be a meg but recently the size got changed).

I'm suprised Mac doesn't see the bug. Are you sure all 100KB are sent? I know
windows and linux should definetly see the problem.

I know what I have to do to fix it. We need to send bits asynchronousy to the
socket channel instead of all in the same pass. I'm not giving necko any time
slices to send out the bits I'm pushing in until I'm done.

Jean-Francois, I'm sorry I didn't write this in here earlier...I could have
saved you some trouble in looking at this bug.

Comment 4

[Jean-Francois Ducarroz]

Yes, it's working well on Mac, the received attachment is complete. Vive le
Mac! Too bad I just got your message now than I an done debugging the compose
part of the send process.

Comment 5

[lchiang]

Still occurring in 9/28 Win32 build.

Comment 6

[lchiang]

changing severity since this is data loss.

Comment 7

[Scott MacGregor]

Warren, we've talked about this in email with jefft and Jean-Francois.
Here's the stack trace showing the smtp protocol writing data into the transport
socket and showing how we are getting blocked on a flush call.
Here's the line we're blocking on and the trace is below.
>         if (mBlocking) {
>             rv = mon.Wait();    // mscott: mon.Wait is never returning
> for us!
>             if (NS_FAILED(rv)) return rv;   // interrupted
>         }

PR_Wait(PRMonitor * 0x00c82890, unsigned int 4294967295) line 155 + 29 bytes
   PR_CWait(void * 0x0384e400, unsigned int 4294967295) line 354 + 13 bytes
   nsAutoCMonitor::Wait(unsigned int 4294967295) line 242 + 16 bytes
   nsPipe::nsPipeOutputStream::Flush(nsPipe::nsPipeOutputStream * const
0x0384e414) line 720 + 10
   bytes
   nsPipe::nsPipeOutputStream::WriteSegments(nsPipe::nsPipeOutputStream * const
0x0384e414,
   unsigned int (void *, char *, unsigned int, unsigned int, unsigned int *)*
0x10032e50
   nsReadFromRawBuffer(void *, char *, unsigned int, unsigned int, unsigned int
*), void * 0x0012f4f0,
   unsigned int 1836, unsigned int * 0x0012f480) line 620 + 12 bytes
   nsPipe::nsPipeOutputStream::Write(nsPipe::nsPipeOutputStream * const
0x0384e414, const char *
   0x0012f4f0, unsigned int 1998, unsigned int * 0x0012f480) line 693
   nsMsgProtocol::SendData(nsIURI * 0x03849664, const char * 0x0012f4f0) line
149 + 47 bytes
   nsSmtpProtocol::SendMessageInFile() line 1109
   nsSmtpProtocol::SendPostData() line 1153 + 8 bytes
   nsSmtpProtocol::ProcessProtocolState(nsIURI * 0x03849664, nsIInputStream *
0x03846dc8,
   unsigned int 240, unsigned int 44) line 1405 + 8 bytes
   nsMsgProtocol::OnDataAvailable(nsMsgProtocol * const 0x038490a0, nsIChannel *
0x0384e530,
   nsISupports * 0x03849664, nsIInputStream * 0x03846dc8, unsigned int 240,
unsigned int 44) line 161
   + 32 bytes
   nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const
0x038412d0) line 359
   nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03841b10) line 152 + 12
bytes
   PL_HandleEvent(PLEvent * 0x03841b10) line 541 + 10 bytes
   PL_ProcessPendingEvents(PLEventQueue * 0x00ced500) line 500 + 9 bytes
   _md_EventReceiverProc(HWND__ * 0xc1e706a4, unsigned int 49366, unsigned int
0, long
   13554944) line 970 + 9 bytes
   USER32! 77e71820()
   00ced500()

Comment 8

[Scott MacGregor]

Per discussions with Warren over email. I think this is a bug in the pipe code
(or socket) involving writing data > than the size of the pipe.

Re-assigning to warren. Leaving the cri priority alone. It would be nice if we
could fix this problem for M10 but it is currently marked for M11. (If you give
me a fix, I'd be willing to check it into the branch).

Comment 9

[Scott MacGregor]

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

Comment 10

[Scott MacGregor]

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

Comment 11

[Katsuhiko Momoi]

From the research I did on Bug 15538, the summary line wording
of "100KB attachment" seems inaccurate. Would you change the summary
line? I would have marked the other bug as a duplicate a lot sooner
if this wording wasn't there.

Comment 12

[Scott MacGregor]

Changing the summary per kat's comments. 8KB is the size of the pipe between the
protocol and the socket channel hence the signfigance of this number.

Comment 13

[Warren Harris]

Attachment: Diffs for xpcom/io/nsPipe2.cpp that I think fix the problem.

Comment 14

[Warren Harris]

I've got a fix that I've attached, but I haven't done enough thorough testing
with them yet. I was hoping that mscott might be able to give them a try too.

Warren

Comment 15

[Scott MacGregor]

Warren, thanks for looking into this. I'm stepping out for a little bit but will
try this out later this evening and get back to you.

Comment 16

[Scott MacGregor]

I checked in warren's fix.

Comment 17

[fenella]

Linux (1999-10-13-08 m11) commercial
Win32 (1999-10-13-09 m11) commercial
Mac (1999-10-13-08 m11) commercial
Is there any maxiumn size that can be attached to a message?
When I the same file (nsMsgSend.cpp) as originally reported, it sends without
any freeze.
But when I sent a file over 100 KB, it sends but temporary freeze for a few
seconds and then recover.  Mark this one verified.

Comment 18

[Warren Harris]

Well, the bigger the file, the longer it will take to send it. However, that
shouldn't freeze the UI. You should open a new bug on this if it's a problem.