208082 - negative unread count for newsgroups

Status: RESOLVED INCOMPLETE

(MailNews Core :: Networking: NNTP, defect)

Description

[L A Walsh]

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

Haven't read or used the ms news groups in probably over a month.  I entered
last week and I never have time to go through a small fraction, but many of the
news groups have an unread count that is negative!

As I look, for example m.p.w.dns says -1336 for unread out of 7441 total.
While m.p.w.general (I think that might be windows xp), says
unread=100209, read=98564.

If I click on the news group, it will update the Unread count to something
'normal' -- a bolded positive number.  But I guess I'm a bit confused with
the non-bolded negative count for unread.  Does that mean I've really read
that many?  (negative unread = positive read?)  

Reproducible: Always

Steps to Reproduce:
1.subscribe to newsgroups on ms server -- maybe high volume helps but dunno
2.don't read news for a month or so, then go back in and see if it happened
3.

Heck if I know...they were never negative before when I was more regularly
reading the news groups.


Expected Results:  
I dunno....since I don't know what the negative number signifies -- maybe the
latest news article on the server has wrapped?  Not all groups have negative
numbers -- some were displayed "normally" even though I didn't enter
them -- m.p.p.shell, forexample says 528/1268....*OUCH*...now this hurts

As i sat here typing, all the groups just updated with positive bolded numbers
except 1 - m.p.p.security still has a negative number (1419/254) .. oops 2 of
them...m.p.w.security also has negative -6071/741.  Very weird.  All looks
normal now except for two microsoft security groups....what's amusing about
this picture....:-)

still don't know what is causing it sigh...

Comment 1

[Karsten Düsterloh]

I've seen this some times, too (with Win2k).
I suspect "shooting" Mozilla (either via explicit kill or crash) if MailNews is
open and there are unread mails in a group as the cause, but haven't been able
to reproduce this, either.

Comment 2

[Robert La Ferla]

This is a duplicate of a bug I filed #205879.  I see this problem frequently. 
It needs to be addressed.

Comment 3

[Karsten Düsterloh]

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

Comment 4

[Nik Johnson]

I have seen this forever on every Windows OS, not just XP, going all the way
back to Moz pre-1.0 versions.  It just looks bad.  Seriously, how can there be a
negative number of messages unread?  At the very least the displayed value
should be changed to "unknown" when a negative number is the result of whatever
calculation tries to figure out the value.

Comment 5

[Karsten Düsterloh]

Attachment: negative count and real values when selected

I'm still not quite sure under which circumstances this occurs. But I've
attached a screen shot showing the negative count and the real values that
appear as soon as the NG is selected.

Comment 6

[Nik Johnson]

Your picture illustrates exactly what I've seen.  It seems to happen in 2
situations (on Windows anyway).  The first is when MailNews (Moz & Tbird) is not
shut down properly.  Open a news server and let the new messages get noted. 
Then hit your system reset button.  After re-boot is complete, opening up the
same news server will show negative numbers IF new messages have been posted. 
The second situation is when I haven't looked at the news server for a week or
so.  It has to be related to a counter overflow somewhere.

Comment 7

[Nik Johnson]

Attachment: Problem Illustration

Here's what my list looks like after not accessing this particular news server
for about a week.

Comment 8

[Henrik Gemal]

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

Comment 9

[Ioldanach]

On User-Agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040124

I also see this.  Any high traffic group, such as binaries groups where the
entire group cycles through in hours or days, will exhibit this behavior.  I've
gone into groups, marked them read, and a couple of days later they show up as
negative numbers.

It seems that if the first available article number is greater than the last
number you read, the unread count goes negative.

Comment 10

[David G King]

So, following the logic from Comment #9, I get to
nsNNTPNewsgroupList::GetRangeOfArtsToDownload in
mozilla/source/mailnews/news/src/nsNNTPNewsgroupList.cpp where the line of code 
rv = args->SetArticleCount(*last - *first + 1); appears, and seems to agree with
the hypothesis.

Comment 11

[tmh]

(In reply to comment #10)
> So, following the logic from Comment #9, I get to
> nsNNTPNewsgroupList::GetRangeOfArtsToDownload in
> mozilla/source/mailnews/news/src/nsNNTPNewsgroupList.cpp where the line of code 
> rv = args->SetArticleCount(*last - *first + 1); appears, and seems to agree with
> the hypothesis.

This is the problem then - that line is clearly wrong.. it fails not only on rewrap, but on any newsgroup that has deleted messages between the first and last... it explains why you get bogus positive values too (a longstanding bug that has been there since the first versin of mozilla I ever used.. see bug 71728).

When you click on the newsgroup it gets the correct value, so clearly it's possible to get the correct value.

Comment 12

[Wayne Mery (:wsmwk)]

see also bug 290826.(In reply to comment #11)
> (In reply to comment #10)
> > So, following the logic from Comment #9, I get to
> > nsNNTPNewsgroupList::GetRangeOfArtsToDownload in
> > mozilla/source/mailnews/news/src/nsNNTPNewsgroupList.cpp where the line of code 
> > rv = args->SetArticleCount(*last - *first + 1); appears, and seems to agree with
> > the hypothesis.
> This is the problem then - that line is clearly wrong.. it fails not only on
> rewrap, but on any newsgroup that has deleted messages between the first and
> last... 
> When you click on the newsgroup it gets the correct value, so clearly it's
> possible to get the correct value.

Does attachment 249378 [details] [diff] [review] in bug 298737 fixed dec 22 on trunk fix this problem?

If not, is a potential patch difficult?

Comment 13

[WADA:World Anti-bad-Duping Agency]

See dependency tree of meta Bug 71728. 
DUP of one of Bug 24592, Bug 34406, Bug 41457, Bug 79130, Bug 108650, Bug 202341.
Sorry but I don't know which bug is correct one to DUP.

Comment 14

[(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 15

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 16

[Wayne Mery (:wsmwk)]

Joshua, see comment 11

Comment 17

[Joshua Cranmer [:jcranmer]]

(In reply to comment #10)
> So, following the logic from Comment #9, I get to
> nsNNTPNewsgroupList::GetRangeOfArtsToDownload in
> mozilla/source/mailnews/news/src/nsNNTPNewsgroupList.cpp where the line of code 
> rv = args->SetArticleCount(*last - *first + 1); appears, and seems to agree with
> the hypothesis.

Yeah, that does not do what you think it does. That is the number of articles that will appear in the "hi, there are N new headers, how many do you want me to download?" dialog and has absolutely no bearing on the number of new messages in the newsgroup. That count may be wrong, but we have to download the headers first to see what the correct number may be, which would defeat the purpose of the dialog.

As there is no other indication of possible failure causes other than vague references to things like expired messages (itself bug 79130), I am going to close this as INCOMPLETE.