Messenger freezes when Sending a Message with 8 KB attachment.



MailNews: Message Display
19 years ago
13 years ago


(Reporter: Suresh, Assigned: Warren Harris)


Windows NT

Firefox Tracking Flags

(Not tracked)



(1 attachment)



19 years ago
Overview Description:
Messenger freezes when Sending a Message with 100 KB attachment. I found this
when doing Performance Testing. The file I attached is

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.


19 years ago
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...
I can see the hang on Window. Can somebody test on UNIX for me please?

Comment 3

19 years ago
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.
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.


19 years ago
Target Milestone: M11


19 years ago
Blocks: 11091


19 years ago
Severity: normal → critical

Comment 5

19 years ago
Still occurring in 9/28 Win32 build.

Comment 6

19 years ago
changing severity since this is data loss.

Comment 7

19 years ago
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
   nsPipe::nsPipeOutputStream::WriteSegments(nsPipe::nsPipeOutputStream * const
   unsigned int (void *, char *, unsigned int, unsigned int, unsigned int *)*
   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 *
   unsigned int 240, unsigned int 44) line 1405 + 8 bytes
   nsMsgProtocol::OnDataAvailable(nsMsgProtocol * const 0x038490a0, nsIChannel *
   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
   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()


19 years ago
Assignee: mscott → warren

Comment 8

19 years ago
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

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


19 years ago

Comment 10

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

Comment 11

19 years ago
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.


19 years ago
Summary: Messenger freezes when Sending a Message with 100 KB attachment. → Messenger freezes when Sending a Message with 8 KB attachment.

Comment 12

19 years ago
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

18 years ago
Created attachment 2009 [details] [diff] [review]
Diffs for xpcom/io/nsPipe2.cpp that I think fix the problem.

Comment 14

18 years ago
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.


Comment 15

18 years ago
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.


18 years ago
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 16

18 years ago
I checked in warren's fix.


18 years ago

Comment 17

18 years ago
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

18 years ago
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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.