219657 - stops getting mail if POP server connection attempt fails

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: POP, defect)

Description

[Jerry Baker]

2003091704 trunk

After some period of time, Mozilla stops retrieving new mail. Pressing the "Get
new messages" button has no effect (Moz doesn't even try - no network activity).
Restarting Mozilla is required. Tried a POP3 log, but it shows nothing unusual.

This has proven difficult to reproduce reliably, but it does happen repeatedly
with the 916 and 917 builds. I am working on reliably reproducing it, but wanted
to document it while it was "fresh".

Comment 1

[Jerry Baker]

I have tried the following theories with no luck so far:

1) That after X number of biffs, Moz just stops. The number of biffs before it 
   stops is random.

2) That receiving a junk mail triggered the problem, but it did not happen after I 
   received another junk message.

3) That, somehow, it was related to form submission (long story), but that isn't 
   it either.

Comment 2

[Jerry Baker]

Attachment: POP3 Log from failure

Here is a POP3 log where biff stopped working for over an hour and "Get new
mail" didn't work either. IP address and path have been obscured, but the rest
is exactly as it was logged.

Comment 3

[Jerry Baker]

*** This bug has been marked as a duplicate of 219449 ***

Comment 4

[David :Bienvenu]

I don't think this is a dup - this bug is about mail retrieval stopping after
some period of time - the other bug is about it not working at all,  I believe.

Comment 5

[Jerry Baker]

Ok. Just that once biff stops working, so does manual "Get new messages"

Comment 6

[Jeff Buhrt]

I have seen this on my laptop multiple times.
I am using the XP 2003091704 build. [I don't use Mozilla mail on the linux
boxes... I have never put VMware on the laptop... I use it for compile/testing
Wind... apps, Linux for development, etc.]

I see the problem after disconnecting the network (which changing rooms) and/or
after leaving Mozilla up overnight. The workaround is stopping Mozilla (all
parts) and restarting. Popping is then fine.

-Jeff

Comment 7

[Jerry Baker]

This is making Mozilla usage difficult. It stops on a regular basis without any
indication. The only way to figure out that it has stopped is to think "gee, I
haven't received any mail for a while"

Comment 8

[Jerry Baker]

For anyone else looking at this, testing has confirmed that this regressed
between the 091510 trunk and 091604 trunk.

Comment 9

[Jerry Baker]

Nominating for blocking 1.5. I don't think releasing a version onto the public
with POP3 broken is such a good thing.

Comment 10

[Christian Eyrich]

Er, Jerry, you see this in the trunk, yes? If you want this as a blocker for
1.5, did you test the 1.5 branch builds, resp. the RCs?

Comment 11

[Jerry Baker]

Er, oops. No. I forgot that they already cut the 1.5 branch. Changing to 1.6.

Comment 12

[David :Bienvenu]

Jerry and I tracked this down to the nsMsgIncomingServer object thinking it was
still busy, for some reason. So either we set that flag and then didn't run a
url at all, or set it and ran a url but didn't clear the flag when the url was done.

Comment 13

[David :Bienvenu]

the reason we think the server is busy is that we're not getting the
OnStopRequest notification. I added logging when we start a url, and when we get
the on stop request: here's the tail of the log, just before the problem happens:

0[265b58]: POP3: Entering state: 15
0[265b58]: POP3: Entering state: 22
0[265b58]: SEND: QUIT

0[265b58]: Entering NET_ProcessPop3 56
0[265b58]: POP3: Entering state: 3
0[265b58]: RECV: +OK nvsvr1.nventure.com POP3 server closing connection
0[265b58]: POP3: Entering state: 41
0[265b58]: POP3: Entering state: 23
0[265b58]: POP3: Entering state: 25
0[265b58]: in on stop request
0[265b58]: WARNING: nsTimeoutImpl::Release() proceeding without context., file
c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 5182
0[265b58]: loading pop3 url
0[265b58]: WARNING: NS_ENSURE_TRUE(mListeners) failed, file
c:/six5/mozilla/mailnews/addrbook/src/nsAddrBookSession.cpp, line 94
0[265b58]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
c:/six5/mozilla/mailnews/addrbook/src/nsAbMDBDirectory.cpp, line 187
0[265b58]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
c:/six5/mozilla/mailnews/addrbook/src/nsAbMDBDirectory.cpp, line 861
0[265b58]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
c:/six5/mozilla/mailnews/addrbook/src/nsAddrDatabase.cpp, line 299
0[265b58]: WARNING: Should not try to set the focus on a disabled window, file
c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2460
0[265b58]: WARNING: Should not try to set the focus on a disabled window, file
c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2460
0[265b58]: WARNING: Should not try to set the focus on a disabled window, file
c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2460
0[265b58]: WARNING: Should not try to set the focus on a disabled window, file
c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2460
0[265b58]: WARNING: Should not try to set the focus on a disabled window, file
c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2460
0[265b58]: WARNING: empty damage rect: update caller to avoid fcn call overhead,
file c:/six5/mozilla/layout/html/base/src/nsFrame.cpp, line 2541
0[265b58]: WARNING: empty damage rect: update caller to avoid fcn call overhead,
file c:/six5/mozilla/layout/html/base/src/nsFrame.cpp, line 2541

Notice that we load the pop url, and we never get into the pop3 protocol state
machine, and we never get an onStopRequest. I see scattered instances of the
WARNINGS throughout the log so I don't know if they're involved or not. I tend
to doubt it.

Comment 14

[David :Bienvenu]

Attachment: socket log of failure when network is down

Comment 15

[Jerry Baker]

Updating summary. If Mozilla attempts to connect to a POP3 server, and the
connection to the server fails, Mozilla refuses to ever get mail again until it
is restarted.

Comment 16

[David :Bienvenu]

dup

*** This bug has been marked as a duplicate of 219376 ***

Comment 17

[Jerry Baker]

I am seeing this problem again in 2003112108 builds.

Comment 18

[benc]

REOPEN: per last comment.
Also, I'm not entirely clear, based on the problem description, that this is
indeed caused by bug 219376.

Comment 19

[David :Bienvenu]

is this still happening with 1.6 final or tbird .4?

Comment 20

[Stephen Wille Padnos]

This does seem to happen on 1.6 final.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

Comment 21

[Andrew Sutherland]

This does happen for me on 1.6 final too.  Very common if Norton Antivirus
installed.  NAV will pop up dialog when infected email arrives (telling user
about it, requiring you to hit "close" to clear dialog).  If user is not there,
it causes some timeout to occur, and all popping stops (as above).

Comment 22

[Mikael Persson]

I get this (or a very similar) bug on Mozilla 1.7.1 as well.

Comment 23

[Mikael Persson]

I sniffeed the packets leading to Mozilla stopping mailcheck of a particular
account. Not reporting SYNs and ACKs the conversation is:

+OK POP3 d1o902.telia.com v7.61 server ready
-ERR Autologout; idle for too long

Comment 24

[James Turner]

> If Mozilla attempts to connect to a POP3 server, and the connection to the
> server fails, Mozilla refuses to ever get mail again until it is restarted.

I have seen this behaviour under Linux as well (Fedora 2/3 and Mandrake 8)
with multiple versions of Mozilla and Thunderbird. Right now I am running
Thunderbird 0.9 (20041127) on Fedora core 3 final. When the problem occurs,
I can press "get mail" but the program won't actually attempt to fetch mail
until after I restart it.

In my case, I think the problem is usually related to switching my laptop
between different networks. Under certain circumstances (to do with VPN
tunnels) my computer can resolve an IP address for my mail server but
cannot actually reach it, so thunderbird tries to contact the server but
times out. If I leave thunderbird online in this configuration, trying to
contact the server automatically every 5 minutes, it _sometimes_ gets into
the state where it stops trying to get mail even when asked to. However,
I have never figured out a 100% repeatable way to reproduce the problem.
On other occasions, thunderbird continues fetching mail as normal once the
route to the mail server is re-established - in fact this is happening most
of the time today when I try to reproduce the problem...

If I remember correctly (sorry to be vague), I have also seen the problem
occur just due to "ordinary network glitches" between the mail server and
client, without any reconfiguring of VPN tunnels, so I don't think it's due
to one particular "weird" setup. 

Please let me know if I can provide more information. I should note that
I'm not an expert in this stuff, just a relatively knowledgeable end user.

Comment 25

[benc]

Is this a state that can be reset by toggling the "offline-online" button? In
some cases, that solved brower problems in necko, temporarily.

Comment 26

[James Turner]

> Is this a state that can be reset by toggling the "offline-online" button? In
> some cases, that solved brower problems in necko, temporarily.

I think I tried that and it did not solve the problem (just now my laptop is
in for repair or I would try again). However, may last comment (#24) may have
been too hasty. It is true that under the circumstances I described,
thunderbird sometimes stops trying to fetch mail - but I discovered that it
(at least) sometimes reverts to normal if I leave it long enough after the
route to the POP server is restored.

I believe that when this problem occured in older versions of Mozilla (eg.
1.4 on Linux), the program never came back to the normal state of being able
to fetch mail until restarted (I was experiencing the problem for some time
before trying Thunderbird 0.9). Having waited a few minutes, I therefore
originally concluded that Thunderbird was doing the same thing.

Sorry if my previous comment was misleading - but it would still be great if,
when Thunderbird gets into this state, pressing "get mail" would make it
try to get messages again immediately instead of having to wait a few minutes.

Comment 27

[SR]

> Is this a state that can be reset by toggling the "offline-online" button? In
> some cases, that solved brower problems in necko, temporarily.

I have tried with several versions of mozilla, and this operation fixes
web connection lost, but does not fix pop connection lost.

This bug is a major bug. It makes thunderbid impossible to use for professional
users, or any serious user.
It may be complex to track, but in my opinion, it should have a high severity
and priority.

Comment 28

[benc]

-> default owners.

Comment 29

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

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 30

[Stephen Wille Padnos]

For what it's worth, I don't see this bug any more.

I'm not sure when it got fixed, or what the culprit may have been (there were server changes at my ISP since my last comment).

Using Mozilla version 1.7.13:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414

Comment 31

[Wayne Mery (:wsmwk)]

do others agree this problem is gone?

Comment 32

[Wayne Mery (:wsmwk)]

=> WFM per comment 30

Comment 33

[James Turner]

I have not seen this same behaviour with recent versions of Thunderbird, though I am now using IMAP rather than POP. Sometimes when Thunderbird has been unable to retrieve mail for a while (eg. due to a lost VPN connection) the "Get Mail" button seems to do nothing for a few minutes after the connection is restored, but eventually (within maybe 5 minutes) it starts working again as normal.