Mozilla stalls trying to download the 89th message. I looked at the message and it wasn't anything special. I'm using Build 1999111609 on Linux.

phil?

Hmm, this doesn't seem right. I tried faking a large spool with one message repeated over and over and mozilla didn't hang on 90 messages. I've got my spool archived, so I'm going to try to narrow down the problem... I don't really want to attach my spool... But I wouldn't mind sending my spool to an individual if they wanted to look at it. I'll post an update soon.

jelwell, are you talking about POP here? NNTP? IMAP?

POP mail Sorry about the poor writeup. I just tested Windows NT: same bad result on Build 1999111520. Changing to All, someone should verfiy on Mac though. In testing it doesn't seem to be the message that got cut off that caused the failure. There is something more complicated going on. I can't seem to pin it down yet.

I changed the title because the number of messages didn't seem to have anything to do with it. And I attached a spool file (pop mail) that causes the hangup.

Reassign to putterman for M12. cc jefft. Change QA contact to lchiang. Lisa, can someone in your group try this out? Mark [dogfood] in case there's a POP data loss issue here.

Esther - can you try to see if you can download a POP mailbox? And then try the mail file that is attached?

Putting on PDT+ radar.

jelwell, can you try most recent builds. We did have some problems with nsPipe2 stuff which was just resolved less than couple weeks ago. I wonder that your build might be too old to have the fix in it.

I tried the attachment on the 1999120108 build, same problem exists. I created a pop mail account on my server for ease of testing, (mostly because I'm looking forward to using mozilla rather than pine and downloading about 300 e-mails to my home computer): POP mail server: mail.singleclick.com user info: mozilla/mozilla you can't telnet in, so don't try! :) but you can download email. :) i'll leave this active until the bug closes.

may be related to another bug report that got submitted today: http://bugzilla.mozilla.org/show_bug.cgi?id=20514

I don't think bug 20514 is related at all. bug 20514 seems to say that she can download all the emails but then she when she clicks on the inbox weird things happen. This bug, 20312, is a problem with downloading. I can't download all my emails. It seems that 1 or 2. All the emails up to the snippet in the attachment download fine, but then when mozilla reaches the emails in the attachment it stops downloading and hangs.

jelwell, I can reproduce the problem using your server. I'll take a look on it. Thanks much for help. Reassign bug to me. jelwell, there is a way to generate pop3 protocol log file. If you are interested, you can set the following environment variable: set NSPR_LOG_FILE=e:\tmp\pop3log.txt set NSPR_LOG_MODULES=POP3:5

I'm also seeing this problem on my windows machine using a POP account. Build used: 1999-12-02-11-M12 and debug build pulled around 11.00 AM today. In my system it stops when downloading 91st message of 102 msgs.

This also happened to me yesterday. It stalled on message 55 out of 1043.

ETA 12-7-1999 to resolve the problem.

The problem went away if I set a breakpoint in nsPop3Protocol.cpp. This sounds like a timing issue of some sorts.

warren, any ideas you may have?

I need backtraces to see what the threads are doing when the deadlock occurs.

warren, here is all the threads stack traces. Starting from top to bottom. I also includes the pop3 protocol log. We stucked while entering the message retrival response state. Thanks for helping. NTDLL! 77f682db() MSAFD! 77664a12() WS2_32! 776b9f5f() _PR_MD_PR_POLL(PRPollDesc * 0x02bcee60, int 2, unsigned int 1919295) line 224 + 35 bytes PR_Poll(PRPollDesc * 0x02bcee60, int 2, unsigned int 1919295) line 115 + 17 bytes nsSocketTransportService::Run(nsSocketTransportService * const 0x02bcd9f4) line 424 + 23 bytes nsThread::Main(void * 0x02bcecb0) line 83 + 26 bytes _PR_NativeRunThread(void * 0x02bceb40) line 399 + 13 bytes _threadstartex(void * 0x02bce990) line 212 + 13 bytes KERNEL32! 77f04ede() USER32! 77e72d04() nsAppShellService::Run(nsAppShellService * const 0x01076ac0) line 489 main1(int 2, char * * 0x01004bc0) line 611 + 32 bytes main(int 2, char * * 0x01004bc0) line 679 + 13 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77f1b9ea() NTDLL! 77f682db() KERNEL32! 77f04f37() _PR_WaitCondVar(PRThread * 0x010fbc10, PRCondVar * 0x010fbd80, PRLock * 0x010ff850, unsigned int 4294967295) line 185 + 23 bytes PR_Wait(PRMonitor * 0x010ffa00, unsigned int 4294967295) line 155 + 29 bytes nsThreadPool::GetRequest() line 396 + 14 bytes nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x010ff9c0) line 591 + 11 bytes nsThread::Main(void * 0x010ff810) line 83 + 26 bytes _PR_NativeRunThread(void * 0x010fbc10) line 399 + 13 bytes _threadstartex(void * 0x010ffc80) line 212 + 13 bytes KERNEL32! 77f04ede() NTDLL! 77f67fa7() RPCRT4! 77e15a1d() NTDLL! 77f682db() MSAFD! 77661e92() 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 4 0[1002a70]: RECV: +OK POP3 ghouda.singleclick.com v6.50 server ready 0[1002a70]: POP3: Entering state: 5 0[1002a70]: SEND: USER mozilla 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 3 0[1002a70]: RECV: +OK User name accepted, password please 0[1002a70]: POP3: Entering state: 6 0[1002a70]: SEND: PASS mozilla 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 3 0[1002a70]: RECV: +OK Mailbox open, 4 messages 0[1002a70]: POP3: Entering state: 7 0[1002a70]: SEND: STAT 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 3 0[1002a70]: RECV: +OK 4 6264 0[1002a70]: POP3: Entering state: 8 0[1002a70]: POP3: Entering state: 9 0[1002a70]: SEND: LIST 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 3 0[1002a70]: RECV: +OK Mailbox scan listing follows 0[1002a70]: POP3: Entering state: 10 0[1002a70]: RECV: 1 944 0[1002a70]: POP3: Entering state: 10 0[1002a70]: RECV: 2 1452 0[1002a70]: POP3: Entering state: 10 0[1002a70]: RECV: 3 2087 0[1002a70]: POP3: Entering state: 10 0[1002a70]: RECV: 4 1781 0[1002a70]: POP3: Entering state: 10 0[1002a70]: RECV: . 0[1002a70]: POP3: Entering state: 11 0[1002a70]: SEND: TOP 4 1 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 3 0[1002a70]: RECV: +OK Top of message follows 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Return-Path: <nobody@mozilla.org> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Received: from lounge.mozilla.org (h-207-200-73-38.netscape.com [207.200.73.38]) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: by ghouda.singleclick.com (8.8.7/8.8.7) with ESMTP id PAA02655 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: for <jelwell@singleclick.com>; Tue, 30 Nov 1999 15:03:42 -0800 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Received: (from nobody@localhost) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: by lounge.mozilla.org with id MAA15176; 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Tue, 30 Nov 1999 12:55:37 -0800 (PST) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Date: Tue, 30 Nov 1999 12:55:37 -0800 (PST) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Message-Id: <199911302055.MAA15176@lounge.mozilla.org> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: From: bugzilla-daemon@mozilla.org 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: To: jelwell@singleclick.com, cpratt@netscape.com 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Subject: [Bug 20227] Changed - Clicking on Form elements causes reflow and misdraw. 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Status: RO 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: http://bugzilla.mozilla.org/show_bug.cgi?id=20227 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: . 0[1002a70]: POP3: Entering state: 27 0[1002a70]: SEND: TOP 3 1 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 3 0[1002a70]: RECV: +OK Top of message follows 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Return-Path: <dyoung@carprices.com> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Received: from mail1.autofusion.com ([216.120.4.22]) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: by ghouda.singleclick.com (8.8.7/8.8.7) with ESMTP id NAA03378 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: for <jelwell@singleclick.com>; Thu, 11 Nov 1999 13:32:52 -0800 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Received: by MAIL1 with Internet Mail Service (5.5.2232.9) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: id <W2TDW58B>; Thu, 11 Nov 1999 12:27:18 -0800 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Message-ID: <EFF378EBA35DD2119DEF00104B758B60285BC4@MAIL1> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: From: David Young <dyoung@carprices.com> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: To: "'Joseph Elwell'" <jelwell@singleclick.com> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Subject: RE: "Leon", director's cut 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Date: Thu, 11 Nov 1999 12:27:17 -0800 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: MIME-Version: 1.0 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: X-Mailer: Internet Mail Service (5.5.2232.9) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Content-Type: text/plain; 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: charset="iso-8859-1" 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Status: RO 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: well, I wouldn't charge less than $50/hr if I was to 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: . 0[1002a70]: POP3: Entering state: 27 0[1002a70]: SEND: TOP 2 1 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 3 0[1002a70]: RECV: +OK Top of message follows 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Return-Path: <dyoung@carprices.com> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Received: from mail1.autofusion.com ([216.120.4.22]) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: by ghouda.singleclick.com (8.8.7/8.8.7) with ESMTP id NAA03326 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: for <jelwell@singleclick.com>; Thu, 11 Nov 1999 13:26:13 -0800 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Received: by MAIL1 with Internet Mail Service (5.5.2232.9) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: id <W2TDW57Z>; Thu, 11 Nov 1999 12:20:49 -0800 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Message-ID: <EFF378EBA35DD2119DEF00104B758B60285BC3@MAIL1> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: From: David Young <dyoung@carprices.com> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: To: "'Joseph Elwell'" <jelwell@singleclick.com> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Subject: RE: "Leon", director's cut 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Date: Thu, 11 Nov 1999 12:20:48 -0800 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: MIME-Version: 1.0 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: X-Mailer: Internet Mail Service (5.5.2232.9) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Content-Type: text/plain; 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: charset="iso-8859-1" 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Status: RO 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: 45/hr contracting.. of course. 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: . 0[1002a70]: POP3: Entering state: 27 0[1002a70]: SEND: TOP 1 1 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 3 0[1002a70]: RECV: +OK Top of message follows 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Return-Path: <dyoung@carprices.com> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Received: from mail1.autofusion.com ([216.120.4.22]) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: by ghouda.singleclick.com (8.8.7/8.8.7) with ESMTP id LAA02493 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: for <jelwell@singleclick.com>; Thu, 11 Nov 1999 11:29:00 -0800 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Received: by MAIL1 with Internet Mail Service (5.5.2232.9) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: id <W2TDW5ZW>; Thu, 11 Nov 1999 10:23:33 -0800 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Message-ID: <EFF378EBA35DD2119DEF00104B758B60285BC2@MAIL1> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: From: David Young <dyoung@carprices.com> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: To: "'jelwell@singleclick.com'" <jelwell@singleclick.com> 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Subject: "Leon", director's cut 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Date: Thu, 11 Nov 1999 10:23:32 -0800 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: MIME-Version: 1.0 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: X-Mailer: Internet Mail Service (5.5.2232.9) 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Content-Type: text/plain; 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: charset="iso-8859-1" 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Status: RO 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: Dude.. 0[1002a70]: POP3: Entering state: 28 0[1002a70]: RECV: . 0[1002a70]: POP3: Entering state: 15 0[1002a70]: POP3: Entering state: 18 0[1002a70]: SEND: RETR 1 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 3 0[1002a70]: RECV: +OK 944 octets 0[1002a70]: POP3: Entering state: 19 0[1002a70]: Opening message stream: MSG_IncorporateBegin 0[1002a70]: Done opening message stream! 0[1002a70]: RECV: Return-Path: <dyoung@carprices.com> 0[1002a70]: RECV: Received: from mail1.autofusion.com ([216.120.4.22]) 0[1002a70]: RECV: by ghouda.singleclick.com (8.8.7/8.8.7) with ESMTP id LAA02493 0[1002a70]: RECV: for <jelwell@singleclick.com>; Thu, 11 Nov 1999 11:29:00 -0800 0[1002a70]: RECV: Received: by MAIL1 with Internet Mail Service (5.5.2232.9) 0[1002a70]: RECV: id <W2TDW5ZW>; Thu, 11 Nov 1999 10:23:33 -0800 0[1002a70]: RECV: Message-ID: <EFF378EBA35DD2119DEF00104B758B60285BC2@MAIL1> 0[1002a70]: RECV: From: David Young <dyoung@carprices.com> 0[1002a70]: RECV: To: "'jelwell@singleclick.com'" <jelwell@singleclick.com> 0[1002a70]: RECV: Subject: "Leon", director's cut 0[1002a70]: RECV: Date: Thu, 11 Nov 1999 10:23:32 -0800 0[1002a70]: RECV: MIME-Version: 1.0 0[1002a70]: RECV: X-Mailer: Internet Mail Service (5.5.2232.9) 0[1002a70]: RECV: Content-Type: text/plain; 0[1002a70]: RECV: charset="iso-8859-1" 0[1002a70]: RECV: Status: RO 0[1002a70]: RECV: 0[1002a70]: RECV: Dude.. 0[1002a70]: RECV: 0[1002a70]: RECV: I borrowed "Leon" (aka. the Professional) Director's cut from 0[1002a70]: RECV: a co-worker today. We can probably watch it tonight... Natalie Portman!! 0[1002a70]: RECV: 0[1002a70]: RECV: oh yeah, you left the garage open when you left this morning.. 0[1002a70]: RECV: and.. send me your resume! 0[1002a70]: RECV: 0[1002a70]: RECV: Dave 0[1002a70]: RECV: . 0[1002a70]: POP3: Entering state: 15 0[1002a70]: POP3: Entering state: 18 0[1002a70]: SEND: RETR 2 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 3 0[1002a70]: RECV: +OK 1452 octets 0[1002a70]: POP3: Entering state: 19 0[1002a70]: Opening message stream: MSG_IncorporateBegin 0[1002a70]: Done opening message stream! 0[1002a70]: RECV: Return-Path: <dyoung@carprices.com> 0[1002a70]: RECV: Received: from mail1.autofusion.com ([216.120.4.22]) 0[1002a70]: RECV: by ghouda.singleclick.com (8.8.7/8.8.7) with ESMTP id NAA03326 0[1002a70]: RECV: for <jelwell@singleclick.com>; Thu, 11 Nov 1999 13:26:13 -0800 0[1002a70]: RECV: Received: by MAIL1 with Internet Mail Service (5.5.2232.9) 0[1002a70]: RECV: id <W2TDW57Z>; Thu, 11 Nov 1999 12:20:49 -0800 0[1002a70]: RECV: Message-ID: <EFF378EBA35DD2119DEF00104B758B60285BC3@MAIL1> 0[1002a70]: RECV: From: David Young <dyoung@carprices.com> 0[1002a70]: RECV: To: "'Joseph Elwell'" <jelwell@singleclick.com> 0[1002a70]: RECV: Subject: RE: "Leon", director's cut 0[1002a70]: RECV: Date: Thu, 11 Nov 1999 12:20:48 -0800 0[1002a70]: RECV: MIME-Version: 1.0 0[1002a70]: RECV: X-Mailer: Internet Mail Service (5.5.2232.9) 0[1002a70]: RECV: Content-Type: text/plain; 0[1002a70]: RECV: charset="iso-8859-1" 0[1002a70]: RECV: Status: RO 0[1002a70]: RECV: 0[1002a70]: RECV: 45/hr contracting.. of course. 0[1002a70]: RECV: it's like over 100k/year in salary. 0[1002a70]: RECV: if I find that job, I'm taking it myself. 0[1002a70]: RECV: 0[1002a70]: RECV: Leon's on VHS 0[1002a70]: RECV: 0[1002a70]: RECV: 0[1002a70]: RECV: dave 0[1002a70]: RECV: 0[1002a70]: RECV: -----Original Message----- 0[1002a70]: RECV: From: Joseph Elwell [mailto:jelwell@singleclick.com] 0[1002a70]: RECV: Sent: Thursday, November 11, 1999 1:24 PM 0[1002a70]: RECV: To: David Young 0[1002a70]: RECV: Subject: Re: "Leon", director's cut 0[1002a70]: Entering NET_ProcessPop3 0[1002a70]: POP3: Entering state: 19

Looks like a pop3 bug to me. Everything is idle, network, file transport and main thread. Pop3 must be getting out of sync and expecting another callback that never comes.

Okay, I look into more on the pop3 protocol side. Thanks much.

This one will be tough to figure out setting breakpoints in nsPop3Protocol.cpp or adding debug logging statements fix the problem. Weird...

Sounds like a race condition somewhere.

Yes, for sure.

I don't have a good grab on this problem but adding enter and exit monitor around accessing input stream seems fix the problem. Since, we are clients of nsPipe2, we might have some race situation around the pipe. Adding monitor could prevent this kind of race, I think. warren, any comments? scott could you try the following patch and let me if this fix your problem. Thanks. Index: nsMsgLineBuffer.cpp =================================================================== RCS file: /cvsroot/mozilla/mailnews/base/util/nsMsgLineBuffer.cpp,v retrieving revision 1.12 diff -c -r1.12 nsMsgLineBuffer.cpp *** nsMsgLineBuffer.cpp 1999/11/06 03:29:27 1.12 --- nsMsgLineBuffer.cpp 1999/12/07 15:51:16 *************** *** 330,336 **** --- 330,339 ---- { PRUint32 numBytesInStream = 0; PRUint32 numBytesCopied = 0; + + PR_CEnterMonitor(aInputStream); aInputStream->Available(&numBytesInStream); + PR_CExitMonitor(aInputStream); // if the number of bytes we want to read from the stream, is greater than the number // of bytes left in our buffer, then we need to shift the start pos and its contents // down to the beginning of m_dataBuffer... *************** *** 344,354 **** numFreeBytesInBuffer = m_dataBufferSize - numBytesInBuffer; } PRUint32 numBytesToCopy = PR_MIN(numFreeBytesInBuffer - 1 /* leave one for a null terminator */, numBytesInStream); // read the data into the end of our data buffer if (numBytesToCopy > 0) { ! aInputStream->Read(m_startPos + numBytesInBuffer, numBytesToCopy, &numBytesCopied); m_startPos[numBytesInBuffer + numBytesCopied] = '\0'; } --- 347,366 ---- numFreeBytesInBuffer = m_dataBufferSize - numBytesInBuffer; } + #if 0 + printf("numFreeBytesInBuffer %d numBytesInStream %d \n", + numFreeBytesInBuffer -1, numBytesInStream); + #endif + PRUint32 numBytesToCopy = PR_MIN(numFreeBytesInBuffer - 1 /* leave one for a null terminator */, numBytesInStream); // read the data into the end of our data buffer if (numBytesToCopy > 0) { ! PR_CEnterMonitor(aInputStream); ! aInputStream->Read(m_startPos + numBytesInBuffer, numBytesToCopy, ! &numBytesCopied); ! PR_CExitMonitor(aInputStream); ! m_startPos[numBytesInBuffer + numBytesCopied] = '\0'; }

I don't see where that lock is doing anything except affecting your timing. It's not protecting anything, or preserving any invariant.

Aren't nsPipe2 stream has auto monitor on itself? I am assuming when using PR_CEnterMonitor() can prevent two threads (netlib thread and ui thread) accessing the same stream at the same time. Maybe I had a bad assumption.

Pipes are thread safe already.

You're right. ReadSegments() & WriteSegments() both have monitor to guard them. Shouldn't need additional monitor. My misunderstanding.

with the patch it seems to have downloaded all of my messages.

As I said, it probably just affects timing, but doesn't fix the problem. I bet if you try it enough times, you'll still hit it.

So, I tried with my own account on nsmail-2. I have more than 4000 messages in my inbox. And sure enough it stalls with the a few assertions in my pop3 log. Any ideas warren? I'll try to look into nsFileTransport.cpp why we are having those assertions. 168[fab620]: Assertion: "didn't transfer all the data" (mTransferAmount == 0 || NS_FAILED(mStatus)) at file f:\mozilla\netwerk\base\src\nsFileTransport.cpp, line 832 168[fab620]: Break: at file f:\mozilla\netwerk\base\src\nsFileTransport.cpp, line 832 168[fab620]: Assertion: "didn't transfer all the data" (mTransferAmount == 0 || NS_FAILED(mStatus)) at file f:\mozilla\netwerk\base\src\nsFileTransport.cpp, line 832 168[fab620]: Break: at file f:\mozilla\netwerk\base\src\nsFileTransport.cpp, line 832 168[fab620]: Assertion: "didn't transfer all the data" (mTransferAmount == 0 || NS_FAILED(mStatus)) at file f:\mozilla\netwerk\base\src\nsFileTransport.cpp, line 832 168[fab620]: Break: at file f:\mozilla\netwerk\base\src\nsFileTransport.cpp, line 832 168[fab620]: Assertion: "didn't transfer all the data" (mTransferAmount == 0 || NS_FAILED(mStatus)) at file f:\mozilla\netwerk\base\src\nsFileTransport.cpp, line 832 168[fab620]: Break: at file f:\mozilla\netwerk\base\src\nsFileTransport.cpp, line 832

Sorry, warren. My previous posting is incorrect. I was confused with my serveral version of log files.

I couldn't reproduce the problem any more with the up-to-date tree. This scares me. Sounds like we have a time bomb somewhere and don't know when it will explode.

Aaah. That's the first I've heard about those assertions. Try setting a breakpoint in nsFileTransport::Cancel to see if it's begin called, who's calling it, and if it's failing to set the mStatus instance variable. So why does pop3 involve the file transport anyway?

I don't think this is a timing issue at all. I'm not certain how that came about other than speculation. I did a little more digging, and I came up with a new, shorter test case, that points the finger more directly at the cause behind this bug. It's this line in one of my e-mail messages: "From: Joseph Elwell [mailto:jelwell@singleclick.com]" If I delete that single line from the message then mozilla downloads all the email just fine. I don't know what most email clients do to seperate the spool file into different messages, but it appears that Mozilla thinks that this is a new message starting in the middle of another message - which is causing this crash. the account is still up, with the new spool file that I will attach shortly. It contains only 1 email message.

I never saw such RFC822 mailbox address formation. Is it legal? I don't think so. What mail client will generate that kind of address? However, even with that, I don't think we should stall.

jefft, I think you're missing the part where there's only one email in the new attachment. That email has a reply in it, so the second From line is part of the email message, it's just info about what the original e-mail was about... So "From: Joseph Elwell [mailto:jelwell@singleclick.com]" isn't meant to be processed as a valid email beginning, it's just text in an email. But it seems that Mozilla is a little confused, and thinks that it might well be the beginning of a new e-mail. That's my guess at least.

I can reproduce the problem with my 4000+ message Inbox. warren, I also set the breakpoints in both nsFileTransport.cpp line 829 (where the assert is) and nsFileTransport::Cancel. I did get hit with assert from time to time but never break inot nsFileTransport::Cancel(). The stack trace when hitting assert follows: nsFileTransport::Process() line 828 nsFileTransport::Run(nsFileTransport * const 0x03319554) line 682 nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x011d12c0) line 594 + 12 bytes nsThread::Main(void * 0x011d1f40) line 83 + 26 bytes _PR_NativeRunThread(void * 0x011d7c30) line 399 + 13 bytes _threadstartex(void * 0x011d0f40) line 212 + 13 bytes KERNEL32! 77f04ee8() NTDLL! 77f6829b() MSAFD! 77664a12() WS2_32! 776b9f5e() _PR_MD_PR_POLL(PRPollDesc * 0x0239b220, int 3, unsigned int 2610055) line 224 + 35 bytes PR_Poll(PRPollDesc * 0x0239b220, int 3, unsigned int 2610055) line 115 + 17 bytes nsSocketTransportService::Run(nsSocketTransportService * const 0x0239b3e4) line 424 + 23 bytes nsThread::Main(void * 0x0239b5a0) line 83 + 26 bytes _PR_NativeRunThread(void * 0x0239cdb0) line 399 + 13 bytes _threadstartex(void * 0x0239cc00) line 212 + 13 bytes KERNEL32! 77f04ee8() USER32! 77e72ada() nsAppShellService::Run(nsAppShellService * const 0x00c58410) line 499 main1(int 2, char * * 0x00be4bf0) line 610 + 32 bytes main(int 2, char * * 0x00be4bf0) line 678 + 13 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77f1ba06() NTDLL! 77f6829b() MSAFD! 77661e92() NTDLL! 77f67f67() RPCRT4! 77e15fa2()

Oops, sorry read too fast, jelwell. The content shouldn't affect the download I would think. The size of the message maybe more sensitive to the mail client. I am wondering we might be hitting the internal buffer boundary which causes the problem the occur.

I think I am losing my mind here. Sorry. We didn't hit the assertion, mTransferAmount has the legitimate value - 0.

My friend said he uses outlook at work. And he just sent me another email with a similar flow, but mozilla downloaded this one ok. It just renders it wrong. Email: From dyoung@carprices.com Tue Dec 7 19:37:31 1999 Return-Path: <dyoung@carprices.com> Received: from mail1.autofusion.com ([216.120.4.22]) by ghouda.singleclick.com (8.8.7/8.8.7) with ESMTP id TAA06672 for <jelwell@singleclick.com>; Tue, 7 Dec 1999 19:37:31 -0800 Received: by MAIL1 with Internet Mail Service (5.5.2232.9) id <Y10LA79K>; Tue, 7 Dec 1999 17:28:17 -0800 Message-ID: <EFF378EBA35DD2119DEF00104B758B60285C09@MAIL1> From: David Young <dyoung@carprices.com> To: "'Joseph Elwell'" <jelwell@singleclick.com> Subject: RE: "Leon", director's cut Date: Tue, 7 Dec 1999 17:28:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Status: RO X-Status: X-Keywords: X-UID: 605 we use outlook at work DY -----Original Message----- From: Joseph Elwell [mailto:jelwell@singleclick.com] Sent: Tuesday, December 07, 1999 7:27 PM To: David Young Subject: RE: "Leon", director's cut Hey, what e-mail client did you use to make this message? joe. On Thu, 11 Nov 1999, David Young wrote: > 45/hr contracting.. of course. > it's like over 100k/year in salary. > if I find that job, I'm taking it myself. > > Leon's on VHS > > > dave > > -----Original Message----- > From: Joseph Elwell [mailto:jelwell@singleclick.com] > Sent: Thursday, November 11, 1999 1:24 PM > To: David Young > Subject: Re: "Leon", director's cut > > > dude. my friend here said i should making a minimum of 45$/hour. > find me that job. > i want to see leon. is it dvd? > joe. > > On Thu, 11 Nov 1999, David Young wrote: > > > Dude.. > > > > I borrowed "Leon" (aka. the Professional) Director's cut from > > a co-worker today. We can probably watch it tonight... Natalie Portman!! > > > > oh yeah, you left the garage open when you left this morning.. > > and.. send me your resume! > > > > Dave > > > The way Mozilla shows it: we use outlook at work DY -----Original Message----- From: Joseph Elwell [we use outlook at work DY -----Original Message----- From: Joseph Elwell [mailto:jelwell@singleclick.com] Sent: Thursday, November 11, 1999 1:24 PM To: David Young Subject: Re: "Leon", director's cut Hey, what e-mail client did you use to make this message? joe. On Thu, 11 Nov 1999, David Young wrote: > 45/hr contracting.. of course. > it's like over 100k/year in salary. > if I find that job, I'm taking it myself. > > Leon's on VHS > > > dave > > -----Original Message----- > From: Joseph Elwell [mailto:jelwell@singleclick.com] > Sent: Thursday, November 11, 1999 1:24 PM > To: David Young > Subject: Re: "Leon", director's cut > > > dude. my friend here said i should making a minimum of 45$/hour. > find me that job. > i want to see leon. is it dvd? > joe. > > On Thu, 11 Nov 1999, David Young wrote: > > > Dude.. > > > > I borrowed "Leon" (aka. the Professional) Director's cut from > > a co-worker today. We can probably watch it tonight... Natalie Portman!! > > > > oh yeah, you left the garage open when you left this morning.. > > and.. send me your resume! > > > > Dave > > > Notice the inserted text, that wasn't in the email: "-----Original Message----- From: Joseph Elwell [we use outlook at work DY " Now i'm lost, maybe it is some weird timing issue because this second email downloads fine, but not the first.

jefft I hope you're not losing your mind because I keep making changes to mozilla's spool on singleclick.com... I'll stop making changes...

Thanks much for your help, jelwell. We'll nail it.

warren, using jelwell's server I can reproduce the problem again. Thanks much, jelwell. We seem looping in the following stack sequence: nsFileTransport::Process() line 738 nsFileTransport::Run(nsFileTransport * const 0x022de9f4) line 682 nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x00cd6be0) line 594 + 12 bytes nsThread::Main(void * 0x00cd6ba0) line 83 + 26 bytes _PR_NativeRunThread(void * 0x00cd7260) line 399 + 13 bytes _threadstartex(void * 0x00cd6800) line 212 + 13 bytes KERNEL32! 77f04ee8() and never end.

Wrong direction again. Loop in nsFileTransport::Process() is for the throbbing image - anithrob.gif.

It turns out this is a dot_fix and pop3 too early to end problem, if you know what I am talking. Indeed, it's a pop3 state machine protocol problem. While fixing this bug I am working on improving the performace with the line stream buffer. We are walking through the line buffer twice when we are trying to read a line. Imaging if you have a 8k buffer, you get hit with 200 PL_strlen() or more.

I am holding of the performance tuning. I couldn't get it work right for imap. I'll log a separate bug for it.

Fix checked in. Couple problems found: 1) we failed in handling empty line if the first line we read is an empty line 2) we don't handle dot in the middle of a message well. nsPop3Protocol.h nsPop3Protocol.cpp modified.

I'm using the latest nightly build on Linux 1999120608 and I still can't download the messages on my account nor the mozilla account I created...

I wonder if this was marked fixed because it works on windows. If so, reading jefft's description of the 2 problems, I'm guessing that the whole linux newline vs. windows newline might be a problem as it has been on some other bugs i've posted on.

but the 120608 build is before the fix was checked in, isn't it?

Very odd. Indeed, I thought I had a more recent version than the fix; because I had just downloaded a nightly build. But it turns on out the nightly builds for linux on www.mozilla.org are dated a bit. Anways, I manually ftp'd over a more recent build 1999121108 but I couldn't verify that this bug is cleared because now mozilla can't even download a single e-mail, from any of my pop accounts. Most be a new bug. Someone else can mark this back to fixed if they want, but i won't until I can actually download my e-mail :) (I also tried 1999121208 and got the same result - no e-mails downloaded)

I'll make sure it works on all platforms. Accepting....

(the new bug mentioned about downloading POP mail on linux is http://bugzilla.mozilla.org/show_bug.cgi?id=21546)

This time for sure. Fix checked in. nsPop3Protocol.cpp changed.

Bug 21546 (Get Msg for POP doesnt work) is fixed in build 1999121321 (win32) and build 1999121320 (linux) and build 1999121314 (mac). jelwell could you please check this again on your system with your mail account using a build mentioned above or later one. Thanks, Esther

I can indeed download all my e-mails just fine on Linux Build 1999121321. However I had to verify that by opening my Inbox by hand because clicking on the Inbox merely collapsed my account tree. I've filed a new bug for that bug 21727, that describes that behaviour in more detail. I don't think this bug is related to the new bug so I'm marking this bug as verified. Thanks, now I can use the e-mail client.