202246 - selecting and opening certain (large) newsgroups in the folder window freezes mozilla

Status: RESOLVED DUPLICATE of bug 185634

(MailNews Core :: Backend, defect)

Description

[Niko Lappalainen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401

Selecting and opening a newsgroup with many new messages may freeze mozilla
(uses 100% of the CPU and no mozilla component responds -> mozilla freezes
completely until killed with task manager). This happens always with a certain
newgroups that has many new messages (the unread count in the folder view).
Other similar newsgroups may open without problems. The solution to be able to
read the messages is to select "Mark Newsgroup Read" and set "View -> Messages
-> All" from the menu to see the messages. The only common thing with the
problematic newsgroups is that they seem to have more than 100 unread messages
when this happened to me.

I have encountered this situation with various version but I have not made notes
which version they were exactly.

This bug is reproducible always this kind of problem newsgroup is found.
Selecting and opening the newsgroup freezes mozilla again and again until the
newsgroup is catched up ("Mark Newsgroup Read").


Reproducible: Always

Steps to Reproduce:
1. See details section.
2.
3.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

I have seen the problem described in this report many times with 1.3
and 1.7.x.  For me, it occurred on newsgroups that have high amounts
of traffic each day.  Clicking on the newsgroup to fetch new headers
for it would cause the CPU to go 100% busy for minutes at a time.  
During that time, the application UI was not responsive.  Clicking
on some of the buttons in the title bar would cause windows to display
a dialog telling me that the application was not responding and offering
to kill it.

The problem got progressively worse and worse (that is, the amount 
of time during which the CPU remained at 100% busy would get longer
and longer).  Finally it reached a point where it seemed to never
finish, not even after 15 minutes.  

I then discovered that the .msf file for that newsgroup had grown 
to several hundred megabytes.  Removing the .msf file eliminated the 
long delay, but the problem started over, and began to grow again.  

As a workaround for the boundlessly growing .msf file problem, 
I configured the news account in mozilla to 
"Keep messages that have arrived in the last [ 7 ] days".
That had prevented the .msf file from ever growing to such a large 
size again.  Since then, occasionally when I open a newsgroup the 
CPU goes 100% busy for a little while, maybe 30 seconds, but that 
is short enough that I am willing to tolerate it.  

However, the workaround seens to have exposed another problem.
Now, the counts of unread and total messages displayed by mozilla
are nonsense when I start the mail-news window, until I actually
download the headers for each group.  I have filed bug 280448 
about that problem.

Comment 2

[Wayne Mery (:wsmwk)]

100 unread messages is not many messages, but if comment 1 is correct then this is probably a dup of bug 11050 or dependent on it.  See also bug 84042, Bug 185634.


(In reply to comment #1)
> ...the workaround seens to have exposed another problem.
> Now, the counts of unread and total messages displayed by mozilla
> are nonsense when I start the mail-news window, until I actually
> download the headers for each group.  I have filed bug 280448 

(FWIW now Bug 108650)

Comment 3

[Wayne Mery (:wsmwk)]

Niko has vanished

Comment 4

[Wayne Mery (:wsmwk)]

Nelson do you stilll see this?

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

I began limiting the number of days that message headers are kept in the 
.msf file over two years ago, and have not seen the problem of the process
going 100% busy for long periods of time when a folder is opened since then.

The problem with incorrect message counts began for me when I did that, and
has persisted to this day.

So, I consider limiting the message header retention time to be a workaround
with a nasty side effect, that (IMO) is still a net improvement.

Comment 6

[Wayne Mery (:wsmwk)]

perf issue in some cases, for practical purposes apparently a hang in others

Comment 7

[Ludovic Hirlimann [:Usul]]

Ok just tested that with latest TB3. Can't see a perf issue and I have a newsgroup with 98k+ unread messages. Maybe something else triggers this.

Comment 8

[Omar Bajraszewski]

I can reproduce it with one news group and Thunderbird (Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.1.5) Gecko/20091112). First I noticed it 6-7 weeks ago. I had to unsubscribe the news group and then subscribe to it again. Yesterday I selected 'rebuild index' from general properties and then Thunderbird started to freeze. I had to unsubscribe my news group again

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Omar Bajraszewski from comment #8)
> I can reproduce it with one news group 

a name and server would have been helpful :)

this sounds like bug 185634