From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9+) Gecko/20010603 BuildID: 2001060320 When retrieving newsgroup headers from certain newsgroups Mozilla freezes after it has retrieved some headers. Then after more than 5 minutes it sometimes continues to retrieve the rest of the headers. Reproducible: Always Steps to Reproduce: 1. Go to the newsgroup that causes Mozilla to freeze (alt.usenet.offline-reader.forte-agent) 2. Download all headers. Actual Results: Mozilla freezes for about 5 minutes (even the throbber stops animating, and Windows says that Mozilla doesn't respond). Expected Results: Mozilla should download the headers without freezing. I'm using a local newsserver on my own computer, and I haven't tried other newsservers. But it works fine with Forté Agent and Outlook Express, so it must be a Mozilla bug.

I don't freeze with build 2001-06-04-09 using news.mcom.com (Collabra 3.52 server). Can you attach an NNTP protocol log? Instruction for windows are at: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap Just substitute NNTP:5 for IMAP:5. Thanks.

Is this the only newsgroup for you that freezes? We had a case where certain threaded messages would cause Mozilla to crash or hang, the fix was checked in, but the older .msf files had to be deleted, and a new profile had to be created.

It's not the only newsgroup that freezes. Most newsgroups works fine but some of them freezes.

Try deleting the .msf for the corresponding newsgroup that freezes. It that works, this bug is a DUP of another bug we fixed where a certain thread style was out of sync with the DB.

It does not solve the problem. Here is a brief description of the problem: 1. The group has about 9500 headers. 2. When I select "Download all headers" it is downloading about 3500 headers, but then it freezes. 3. 1-2 minutes later it continues to retrieve about 500 headers. Then it freezes again for about ½ minute. 4. It does this several times (retrieve 500 headers, freeze ½ minute). 5. When it has retrieved about 8500 headers it retrieves the last 1000 headers.

I am seeing this too, when retrieving many headers (the >500 headers dialogue appears). CVS pulled 0000 UTC 15th June: Strace shows this: gettimeofday({992596304, 121136}, NULL) = 0 write(9, "8", 1) = 1 kill(17090, SIGRT_0) = 0 gettimeofday({992596304, 950321}, NULL) = 0 gettimeofday({992596306, 588401}, NULL) = 0 gettimeofday({992596307, 1387}, NULL) = 0 write(9, "8", 1) = 1 kill(17090, SIGRT_0) = 0 brk(0x971a000) = 0x971a000 gettimeofday({992596308, 449271}, NULL) = 0 gettimeofday({992596308, 850879}, NULL) = 0 write(9, "8", 1) = 1 kill(17090, SIGRT_0) = 0 brk(0x971e000) = 0x971e000 gettimeofday({992596311, 400686}, NULL) = 0 gettimeofday({992596312, 674598}, NULL) = 0 write(9, "8", 1) = 1 kill(17090, SIGRT_0) = 0 ...and so on.

Confirming

stephend, is the the recent regression we were talking about last night (or two nights ago)? It used to behave better, I swear. any guess when it regressed? the NNTP protocol runs on the UI thread. when doing XOVER, we process some of the XOVER data and set a timer (so the UI thread can do work) and when the timer fires, process some more, and so on. from nsNNTPProtocol.cpp #define READ_NEWS_LIST_COUNT_MAX 500 /* number of groups to process at a time wh en reading the list from the server */ #define READ_NEWS_LIST_TIMEOUT 50 /* uSec to wait until doing more */

Seth, there are really a number of new bugs that I think might be related: Bug 86945 might be an outright DUP of this, I'm not sure. (header freezing) Bug 84977 - a bug that Bienvenu owns about an INVALID_POINTER error Bug 86165 - Bradley's bug about crashing on news.netscape.com (using 500 headers at a time as the download limit). Other than the bug I logged, I haven't crashed in these groups with my builds on the trunk...

The bug I filed might be a dup of this: bug 87164

I'm specifically talking about the bug you mentioned where we finish downloading, no crash or anything, but we don't update the UI often enough. yes, #87164 is the one I was thinking of, thanks.

*** Bug 101065 has been marked as a duplicate of this bug. ***

Could you guys use another log or two that may help to indicate the problem? I'm currently seeing the behaviour described on netscape.public.mozilla.mail-news (and many other n.p.m.* groups) with only 30-60 messages to download, not hundreds or thousands. (I can even put the browser UI into a tight, unresponsive loop if I try hard enough.) Deleting the .msf file doesn't fix the problem--if I tell mailnews to download only the most recent 50 messages and mark the rest read when entering the group, it will often die similarly.

I agree with stephend that this bug is likely to be a duplicate of bug 87164, but it doesn't hurt to have them both open until we have proof that they are dups. Peter: yes, please attach a log file - the more log files, the better chance that we can see a 'pattern' and therefore get a better understanding of what the bug involves.

After freezing the header download in mailnews, I continued to try other newsgroups. This log is a continuation from the last line of attachment 64609 [details] to the point where I had to kill the mozilla-bin process.

I tried downloading 100 messages from npm.mail-news and marking the rest as read - no problem occured. I also tried downloading a large number of headers, and it never 'froze' for more than a second (normal). This worksforme, Windows 98, build 2002-01-17

I still get the same behaviour on Linux 2002011613 trunk, although only on my home PC (connected via ISDN). The T1-connected host at work, configured almost identically, seems fine.

*** Bug 124345 has been marked as a duplicate of this bug. ***

*** Bug 134493 has been marked as a duplicate of this bug. ***

Clarifying summary a bit, since we are seeing this issue only when a newsgroup contains a large number of headers. Changing Platform to All since we have a duplicate on Linux.

I see something similar when the newsgroup has a new message that belongs to a long thread (~500 msgs) - it takes Mozilla ~10 sec to open the thread (and it's completely frozen while it's working on it). I reproducibly see this on RedHat Linux for at least several months and up to BuildID as recent as 2002051509 (trunk).

I'm not 100% positive, but David's comments in: http://bugzilla.mozilla.org/show_bug.cgi?id=123677#c5 seem related.

I got excactly the same behaviour by downloading about 18000 headers in a newsgroup which contains some threads with more than 1000 messages. I also tried another newsgroup which did not cause Mozilla to freeze. I guess it's because it did not contain very large threads. I'm using my ISP's newsserver. The newsgroup that causes Mozilla to freeze is dk.snak.

Same thing here. Thunderbird 1.0.6 after about 19000 headers, it crashes.

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

If you saw this in the past, please comment as to whether does or does not still afflict you in a current release, and specify version 2.x or trunk. Notes: - reporter email address is dead, so your feedback is needed. - this is not about long threads, afaict

I don't see this in Thunderbird 2.0.0.9 under Linux (Fedora 8, x86_64).

I haven't noticed the error in Thunderbird 2.0.0.9 under both Linux (Ubuntu 7.10, 32 bit) and Windows.

=> WFM then. thanks for the feedback. WFM also