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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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)
Niko has vanished
QA Contact: esther
Whiteboard: workaround, set "delete messages more than NN days old"
Nelson do you stilll see this?
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.
perf issue in some cases, for practical purposes apparently a hang in others
Assignee: mail → nobody
Component: MailNews: Main Mail Window → MailNews: Backend
Keywords: hang, perf
OS: Windows XP → All
Product: Mozilla Application Suite → Core
QA Contact: backend
Hardware: PC → All
Product: Core → MailNews Core
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.
I can reproduce it with one news group and Thunderbird (Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:126.96.36.199) 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
(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
Severity: critical → major
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Summary: selecting and opening certain newsgroups in the folder window freezes mozilla → selecting and opening certain (large) newsgroups in the folder window freezes mozilla
Duplicate of bug: 185634
You need to log in before you can comment on or make changes to this bug.