[DOGFOOD] Messenger freezes while downloading msgs for a IMAP account.

VERIFIED FIXED in M13

Status

defect
P3
critical
VERIFIED FIXED
20 years ago
11 years ago

People

(Reporter: skasinathan, Assigned: dougt)

Tracking

({smoketest})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] fixes in hand, waiting for review from NSPR folks.)

Attachments

(1 attachment)

Reporter

Description

20 years ago
I tried to load 2 folders that have 1000 and 500 msgs and no summary files. It
was able to download only some messages. The status bar shows "1000 Messages
Receiving: Message headers 271 of 1001" and the application freezes.  This
happens on IMAP account ony. POP accounts works fine.

Build used: 2000-01-14-09-M13, windows commercial build. Tested on 133 Mhz, 64
MB RAM.

Additional info: It works fine on my other windows machine (Win NT 4.0, 400
Mhz).

Updated

20 years ago
Assignee: mscott → bienvenu

Comment 1

20 years ago
david, here's the same symptom that robert was seeing yesterday on his windows
machine. I wonder if it is related to the semaphore work you did the other day?

Comment 2

20 years ago
I doubt it - Robert undid my changes and he still had the problem.
Reporter

Comment 3

20 years ago
I take back the build id. I actually used 2000-01-13-15-M13, Windows commercial
build.

Updated

20 years ago
Severity: normal → critical

Comment 4

20 years ago
Perhaps this has to do with machine speed?  On the same machine that Suresh is
using, he is unable to load any web pages (ie. mail start page, browser default
page) without crashing.

Comment 5

20 years ago
would an IMAP log file help?

Comment 6

20 years ago
*** Bug 24272 has been marked as a duplicate of this bug. ***

Comment 7

20 years ago
*** Bug 24151 has been marked as a duplicate of this bug. ***

Updated

20 years ago
Target Milestone: M14

Comment 8

20 years ago
this seems to be a problem with resources getting consumed faster than win98 can
deal with them. I took out my semaphore changes; that DID NOT fix the problem. I
suspect now that the problem arose when I replaced our hand-rolled proxy stuff
with xpcom proxying. I can't undo that, unfortunately.
This feels like a bug we had in 4.5 - we were getting data from the imap server
faster than we could handle it, and winsock ended up using all of our data
buffers, because it got starved.

One thing the auto proxy stuff does that is different from the old imap proxy
stuff is that it spins in a tight loop waiting for event completion, instead of
waiting for a monitor. I might try to change the proxy code to work that way and
see if it helps.

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 9

20 years ago
Ooh la la, this is a fun one. The things I've tried that haven't helped include
- turning off progress and status, increasing the input stream buffer size,
turning off biff, reducing the number of headers we get at once (from 200 to
40). I've verified that we do indeed block and read all the data from the
socket, parse it, and add it to the database before we ask for the next set of
headers. So I'm mystified - I still suspect something to do with the xpcom proxy
stuff, but I don't see how it could be filling up event queues.

Comment 10

20 years ago
I hate to suggest it, but I did turn on imap's use of the memory cache the same
time you removed your semaphore stuff. And right afterwards, Win98 started
stalling when downloading the inbox for headers.

You could always try to turn it off just for kicks...although I can't see how it
could be getting invoked for a non display url.

Look in nsImapMockChannel::AsyncRead for the code that uses the cache.

Comment 11

20 years ago
thanks, I guess I'll try it. But I'm sure this has nothing to do with my
semaphore changes because it still happens after I put the semaphores back.

Comment 12

20 years ago
I didn't mean to insinuate that your semaphore changes caused it. In fact, I was
insinuating the opposite. The problem occurred around the time frame that your
semaphore changes and my imap memory cache changes both got checked in. You had
already verified it wasn't the semaphore stuff so I was suggesting maybe it was
my stuff =).

I wonder if xpcom proxy changed recently or it was the fact that as you said we
now use the proxy for more stuff in imap..hmmm

Comment 13

20 years ago
No, I understand, and I did verify that your code doesn't get called in this
situation. I was just documenting for posterity in this bug report that it's not
the semaphore changes - I believe it's the changes to use auto proxy for folder
sinks instead of hand-rolled proxy.

Comment 14

20 years ago
Marking dogfood, PDT+ (we talked about it in today's PDT mtg), and M13. Seems
like it's a bad bug, but no fix is imminent. We'll reevaluate it for M13 in a
day or two. David, if it would help to have other people involved with this, we
should do that.
Summary: Messenger freezes while downloading msgs for a IMAP account. → [DOGFOOD] Messenger freezes while downloading msgs for a IMAP account.
Whiteboard: [PDT+]
Target Milestone: M14 → M13

Comment 15

20 years ago
If I stop proxying the header downloading calls and instead call directly into
the nsImapMailFolderSink, this bug goes away. This doesn't mean the problem is
with the proxy code (it could be a timing thing, for example, since it's a lot
faster to call directly into the imap folder sink), but it is suspicious.
Obviously, I can't check this change in, but it is a small bit of progress, and
reinforces my believe that it was the change to auto proxy from hand-rolled
proxy that caused this bug. I'll poke around the proxy code and see if anything
stands out.

Comment 16

20 years ago
I think this has to do with the number of proxied calls I make on an interface.
If I proxy every call, I die after around 220 messages. If I proxy one out of
three calls, I die after 660 messages. If I proxy half the calls I die around
330 proxy calls. So it seems like there's some sort of leak or limit to the
number of calls you can proxy on an interface. One thing I've noticed is that we
create and destroy a native event queue for every event, as near as I can tell.
This seems wrong.

Comment 17

20 years ago
Phil - this is the same bug I was seeing with the 1/19 build on win 98. I
deleted my user profile to attempt a "clean" install because of an install bug
and I have about 1000 messages in my inbox on the server. Seamonkey freezes
after 200 or so messages are downloaded so I can't use mail now.
Assignee

Comment 18

20 years ago
chriss, do you have a bug number?

Comment 19

20 years ago
I may have marked Chris's a dup of this one. Which it is.
Assignee

Comment 20

20 years ago
bienvenu regarding your comment on 2000-01-18, xpcom proxy if fact, does wait
on a monitor during PostAndWait().

Comment 21

20 years ago
Yeah, I eventually figured that out - it waits for the monitor that gets
notified when it gets an event.

Comment 22

20 years ago
FWIW: I'm reading email on IMAP today.  I have in excess of 3000 messages in my
inbox... and life is lookin' good.  I didn't see comments that suggest this is
fixed... but I'm not seeing this on my sweetlou generated optimized build
(2000011908).

Comment 23

20 years ago
Jar, this problem was only on Win95/98...I thought you were using NT...maybe I'm
mistaken though =).

Comment 24

20 years ago
Jim - also you need to start with no summary files (e.g. an empty mail folder)

Comment 25

20 years ago
JAR runs NT. You don't have to start with no summary files, you just have to
download more than one or two hundred headers on win95 or win98.
Assignee

Comment 26

20 years ago
dveditz saw a similar sounding problem which involved xpinstall (which uses
xpcom/proxy as well).  cc-ing him.  dveditz, did you find a fix?
The XPInstall bug 22005 seems similar. If the install does too many files we
run out of 16-bit USER resources and the machine hangs or crashes. If the
number of files is small enough to not crash we run up the resources but get
them back when we dismiss the dialog. If I comment out the code that updates
the dialog via a proxy we don't have a problem (other than not showing any
progress that is).

Comment 28

20 years ago
Yes, 22005 sounds like the same problem. I'd like to get winsock out of the
picture and see if just doing a few hundred proxy calls causes this. I'll try
that next.

Comment 29

20 years ago
I added a rudimentary PLEventQueue cache to EventQueueEntry - it did seem to
speed things up, at least to my fevered imagination, but it didn't fix the
problem.

Updated

20 years ago
Whiteboard: [PDT+] → [PDT+] no fix in hand yet.
Assignee

Comment 31

20 years ago
I think that we have isolated the problem to plevents.  David, could you give a 
whirl?  

Comment 32

20 years ago
With Doug's patch, and my change to PL_DestroyEventQueue as follows (adding the 
DestroyWindow call), I can download a large imap folder. It still sometimes 
stalls, and I'm having trouble loading messages, but things do look better.

PR_IMPLEMENT(void)
PL_DestroyEventQueue(PLEventQueue* self)
{
    PR_EnterMonitor(self->monitor);

    /* destroy undelivered events */
    PL_MapEvents(self, _pl_destroyEvent, NULL);

    if ( self->type == EventQueueIsNative )
        _pl_CleanupNativeNotifier(self);

    /* destroying the monitor also destroys the name */
    PR_ExitMonitor(self->monitor);
    PR_DestroyMonitor(self->monitor);
#if defined(_WIN32) || defined(WIN16)
	DestroyWindow(self->eventReceiverWindow);
#endif
    PR_DELETE(self);

}

Whiteboard: [PDT+] no fix in hand yet. → [PDT+] fixes in hand, waiting for review from NSPR folks.

Comment 33

20 years ago
reassigning to Doug. He has the fixes.
Assignee: bienvenu → dougt
Status: ASSIGNED → NEW

Comment 34

20 years ago
I checked in Doug and David's patches to plevent.c.
/cvsroot/mozilla/nsprpub/lib/ds/plevent.c, revision 3.34

Comment 35

20 years ago
Dougt:  Please check this into the M13 branch.  Thx. :-)

Comment 36

20 years ago
oops... only folks like wtc can check in... wtc: can you land this change on the  
M13 branch Meamonkey_M13_BRANCH
thx

Comment 37

20 years ago
Ugh... three times is the charm... the branch tag is:

SeaMonkey_M13_BRANCH

not upper case M in monkey

Comment 38

20 years ago
bad news one this one I think.
after the first m14 carpool when the new timer changes and wtc landed 
the new version of plevent.c several folks (evaughan,leaf,chrisn,myself)
began seeing hangs and crashes at startup when going through the 
profile manager code paths.  micheal.lowe pulled a clean build from the
trunk to investigate if the new timer code was causing the hangs/crashes,
but we determined if he backed out to the previous rev. of plevent.c
the startup crashes were no longer reproducable.

we need to back out plevent.c to allow folks to get started on testing
m14 builds, and relook at this fix to see how it interacts with 
the profile manager at startup.

lets also not check this in to the SeaMonkey_M13_BRANCH until
we get some more investigation and sort this out.
Keywords: smoketest

Comment 39

20 years ago
check the builds news group for more details on the start up
problem.  "mozilla only runs once." thread

Comment 40

20 years ago
I backed out previous checkin to plevent.c
/cvsroot/mozilla/nsprpub/lib/ds/plevent.c, revision 3.35

Comment 41

20 years ago
doug/wtc, can you get the modified fix on the SeaMonkey_M13_BRANCH ?

thanks.

Comment 42

20 years ago
I reviewed and checked in dougt and bienvenu's modified
fix on the SeaMonkey_M13_BRANCH.
/cvsroot/mozilla/nsprpub/lib/ds/plevent.c, revision 3.33.10.1

Comment 43

20 years ago
is it checked into the tip on m14? I was hoping we could do that first and get a
day of testing with that.

Comment 44

20 years ago
It's not checked into the tip yet because
the tree is closed right now.

Comment 45

20 years ago
Doug's doing a carpool, I bet you can get in with him if you ask :-)

Comment 46

20 years ago
I checked in dougt and bienvenu's modified fix on the main trunk.
/cvsroot/mozilla/nsprpub/lib/ds/plevent.c, revision 3.36

Comment 47

20 years ago
Can you confirm?  If on trunk only, this fix is for M14.  Not on the M13 
branch..correct?

Comment 48

20 years ago
I first checked in dougt and bienvenu's modified fix
on the SeaMonkey_M13_BRANCH, and then on the main trunk
after the tree was opened.
Assignee

Comment 49

20 years ago
marking as fixed now.  thanks bienvenu and wtc!
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED

Comment 50

20 years ago
Using win and linux builds 2000012520m13 and mac build 2000012603m13 this is 
fixed.  To test it I removed my .msf file for (2) of my folders: Inbox (which 
had 727 messages) and buzilla bugs (which had 1466 messages).  I then opened 
messenger and selected each of those folders.  All messages downloaded without a 
pause or hang.  This is the test I used to reproduce the problem on an already 
existing profile and it failed before the fix went it.  If this test scenario 
isn't correctly testing the problem, please reopen and give me a test case.  
Verified
Status: RESOLVED → VERIFIED

Updated

20 years ago
QA Contact: lchiang → esther
Reporter

Comment 51

20 years ago
Additional Info: I tested this on the system on which this bug is reported and 
it works fine. Able to download all headers on an IMAP account and tested on 
2000-01-25-20-M13 Windows commercial build. 
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.