Last modified: 2007-09-07 10:34:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4650 - Special:Statistics gives impossibly large/small counts due to underflow
Special:Statistics gives impossibly large/small counts due to underflow
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.11.x
All All
: Normal minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://ash.crazydreams.org/index.php?...
: easy
: 7378 9192 10600 11220 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-18 06:16 UTC by M. Alan Thomas II
Modified: 2007-09-07 10:34 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description M. Alan Thomas II 2006-01-18 06:16:01 UTC
Upon installation, Special:Statistics gave correct information for the number of "probably 
legitimate content pages" (0).  During the course of customization, I renamed a few of the 
namespaces, and (probably more importantly) moved the Main Page to the Project: namespace (here 
renamed Meta:) and altered MediaWiki:Mainpage to point there as well.  I then deleted the redirect 
created by the move.  After these customizations, the Special:Statistics page gave the following:

There are 1,279 total pages in the database. This includes "talk" pages, pages about Æ, 
minimal "stub" pages, redirects, and others that probably don't qualify as content pages. Excluding 
those, there are 18,446,744,073,709,551,615 pages that are probably legitimate content pages.

Obviously I didn't have 18,446,744,073,709,551,615 pages to be legitimate content.  I created a 
page in the primary namespace and checked the statistics again:

There are 1,280 total pages in the database. This includes "talk" pages, pages about Æ, 
minimal "stub" pages, redirects, and others that probably don't qualify as content pages. Excluding 
those, there are 0 pages that are probably legitimate content pages.

Fine.  Now I deleted the page and re-checked; I got the first message again, verbatim.  I undeleted 
the page and the message did not change.  That is to say, after the delete I received . . .

There are 1,279 total pages in the database. This includes "talk" pages, pages about Æ, 
minimal "stub" pages, redirects, and others that probably don't qualify as content pages. Excluding 
those, there are 18,446,744,073,709,551,615 pages that are probably legitimate content pages.

. . . regardless of an undelete.

I suppose that qualifies as two bugs, actually; let me know if you want me to re-file this report 
so that they can be separated.

In case it matters, my PHP and MySQL versions are listed by Special:Version as the following:
PHP: 4.3.2 (apache2filter) 
MySQL: 3.23.58
Comment 1 Mark Clements (HappyDog) 2006-04-17 10:49:21 UTC
The '1279' total pages is correct, as it includes pages in other namespaces,
including the Mediawiki: namespace, which is populated with all the interface
text when the system is installed.

Presumably the very long article account occurs because the code subtracts one
from the total for the 'Main Page' as this does not count as an article. As
there is no main page nor any other articles in the main space, the code
subtracts one from zero, causing the counter to wrap round to the highest
possible number it can hold, hence the huge number that is being displayed.

I would suggest that the software is modified so it doesn't subtract 1 from the
count, as the main page would be considered legitimate content in a lot of
projects, and in the current WM projects where there are hundreds of thousands
of articles, an extra one makes little difference.
Comment 2 Rob Church 2006-10-30 03:44:28 UTC
*** Bug 7378 has been marked as a duplicate of this bug. ***
Comment 3 Rob Church 2007-03-06 17:50:53 UTC
*** Bug 9192 has been marked as a duplicate of this bug. ***
Comment 4 Brion Vibber 2007-03-06 19:42:55 UTC
Recommended fixes:
a) Change the field from unsigned to signed
b) Fix the UPDATE to prevent underflows below 0 when the page counters are
decremented.

(Perhaps having it regenerate the stats when an invalid value is detected
wouldn't hurt.)
Comment 5 Thomas "Tango" Dalton 2007-06-15 15:19:09 UTC
Doesn't (b) make (a) unnecessary? It should never be negative, so it seems wasteful to have it signed.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-15 22:28:45 UTC
(a) does not make (b) unnecessary, it would just have to detect overflows instead of underflows.
Comment 7 Thomas "Tango" Dalton 2007-06-15 22:41:48 UTC
I said (b) makes (a) unnecessary, not the other way around.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-15 23:01:00 UTC
Er, right, but you confused me by saying it's wasteful to have it signed.  Doesn't that imply you agree with (a) too?  (b) does make (a) unnecessary, strictly speaking, but there's no reason not to allow people to have more than 2,000,000,000 articles (see http://www.gaiaonline.com/, with over a billion posts . . . yikes).
Comment 9 Thomas "Tango" Dalton 2007-06-15 23:19:54 UTC
I think you're reading (a) backwards as well. It is currently unsigned, Brion is suggesting making it signed.
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-17 01:27:39 UTC
Hah, you're right there too.  Never mind, I give up.  :P
Comment 11 Roan Kattouw 2007-07-03 15:50:38 UTC
Has this been fixed yet?
Comment 12 Brion Vibber 2007-07-03 17:58:28 UTC
The sensible thing is probably to add some sanity checking into the SiteStats class lazy initialization.

Currently it checks for an empty or missing row and recounts the data; checking for invalid data (negative counts or impossibly high and thus wraparound counts) could do the same.

The UPDATEs for decrementing could also do a check there, maybe.
Comment 13 Rob Church 2007-07-16 15:00:42 UTC
*** Bug 10600 has been marked as a duplicate of this bug. ***
Comment 14 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-16 15:31:18 UTC
(Let's keep the summary human-readable, here.)
Comment 15 Dario Alpern 2007-07-16 18:57:57 UTC
I don't think the bug 10600 is the same mentioned in the summary. Where does the number -1396 (the number of images) in es.wikipedia.org come from?
Comment 16 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-16 19:19:06 UTC
Underflow.  It's the same issue.
Comment 17 Dario Alpern 2007-07-16 19:29:09 UTC
The number of images starts at zero. It increments when an image is uploaded and it decrements when it is erased, so that number cannot be less than zero. Why there is an underflow down to -1396 images?
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-16 19:49:06 UTC
Beats me, but who cares?  It should be caught at display time even if you manually alter the database.  Fixed in r24176.
Comment 19 Thomas "Tango" Dalton 2007-07-16 20:16:17 UTC
Sanity checking is great, but we should try and keep things sane in the first place.
Comment 20 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-16 20:33:13 UTC
Reasonable, but I don't see any paths in the code that could lead to image creation without triggering site_stats updates, at a superficial look.  If the problem is discovered, well and good, but until then it's best to just make sure the stats get regenerated occasionally (which I'm not sure we do, but if we don't we probably should).
Comment 21 Roan Kattouw 2007-09-07 10:34:53 UTC
*** Bug 11220 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links