Closed Bug 20312 Opened 25 years ago Closed 25 years ago

[DOGFOOD] Mozilla Mail stalls on specified popmail spool.

Categories

(MailNews Core :: Networking, defect, P3)

Product:
MailNews Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jelwell, Assigned: jefft)

Details

(Whiteboard: [PDT+] ETA 12-10 - I have a fix now, I am doing more testing on it)

Attachments

(2 files)

Test Spool File that kills download.
6.73 KB, text/plain
Details
New shortened test case. This one demonstrates the broken From line.
1.96 KB, text/plain
Details 
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.
Assignee: dougt → phil
Component: Silent Download → Networking-Mail
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?
OS: Linux → All
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.

    
  
Summary: Can't download more than 89 messages at a time. → Mozilla Mail stalls on specified popmail spool.

    
    

    
  
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.

    
  
Assignee: phil → putterman
QA Contact: gbush → lchiang
Summary: Mozilla Mail stalls on specified popmail spool. → [DOGFOOD] Mozilla Mail stalls on specified popmail spool.
Target Milestone: M12

    
    

    
  
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?
QA Contact: lchiang → esther

    
  
Whiteboard: [PDT+]

    
    

    
  
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.

    
  
Assignee: putterman → jefft

    
    

    
  
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.

    
  
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] ETA 12-7-1999

    
    

    
  
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.

    
  
Whiteboard: [PDT+] ETA 12-7-1999 → [PDT+] NO ETA -- it's a timing issue, no idea how to fix 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.

    
  
Whiteboard: [PDT+] NO ETA -- it's a timing issue, no idea how to fix it → [PDT+] ETA 12-10 - I have a fix now, I am doing more testing on it

    
    

    
  
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED

    
  
Status: RESOLVED → REOPENED

    
    

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

    
  
Resolution: FIXED → ---

    
    

    
  
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?

    
  
Blocks: 21564

    
    

    
  
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)

    
  
Status: REOPENED → ASSIGNED

    
    

    
  
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)

    
  
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED

    
    

    
  
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

    
  
Status: RESOLVED → VERIFIED

    
    

    
  
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.

    
  
Blocks: 22176

    
  
No longer blocks: 21564

    
  
No longer blocks: 22176
Product: MailNews → Core
Product: Core → MailNews Core

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: