Last modified: 2012-01-23 20:09:49 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 6356 - ParserFunctions MOD result sometimes wrong
ParserFunctions MOD result sometimes wrong
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
Other All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks: 17468
  Show dependency treegraph
Reported: 2006-06-18 09:58 UTC by omniplex
Modified: 2012-01-23 20:09 UTC (History)
3 users (show)

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

Fixes bug by using bcmod(). Performance impact unknown. (499 bytes, patch)
2006-06-18 21:40 UTC, Edward Z. Yang
Conditionally calls bcmath to fix bug if bcmath is installed (932 bytes, patch)
2006-06-19 14:36 UTC, Edward Z. Yang

Description omniplex 2006-06-18 09:58:41 UTC
{{#expr: 20060618093259 mod 10000}} gives mostly 3259 as it should,
but sometimes the result is -6357.

It needs several (about 20) attempts to see it, test it with URL

Not related to [[mediazilla:6068]], tested version 1.7alpha (r14796)
Comment 1 Edward Z. Yang 2006-06-18 21:33:07 UTC
This has to do with overflows. PHP's modulus overflows very easily. This PHP
bug: says that occasionally, PHP will
intercept the operation and use bcmath, but it's better to just use it

Executing the following code in PHP 5.1.2 will consistently give -6357:

echo (20060618093259 % 10000);

This gives the correct result:

echo bcmod('20060618093259', 10000);

However, using BC math may pose an unacceptable performance degradation.
Comment 2 Edward Z. Yang 2006-06-18 21:36:30 UTC
This bug will probably be fixed if Bug 6068 is fixed, but this one can also be
fixed independently.
Comment 3 Edward Z. Yang 2006-06-18 21:40:23 UTC
Created attachment 1985 [details]
Fixes bug by using bcmod(). Performance impact unknown.
Comment 4 Brion Vibber 2006-06-18 21:43:33 UTC
bcmath is not compiled in by default, so I would recommend 
against using it unconditionally. It would make the extension 
useless to many, perhaps most people.
Comment 5 Edward Z. Yang 2006-06-19 14:15:47 UTC
I'll look into making it conditional (at another performance hit!)

Could this be sporadic because of configuration differences between servers? The
load-balancer then is causing it to randomly hit servers that serve negative
Comment 6 Edward Z. Yang 2006-06-19 14:21:29 UTC
I did a whole bunch of reloads on the bug page and noted which server had served
it. Here are the results:

srv2  x2
srv15 x2
srv22 x2

no error
srv62 x2
srv90 x2

I definitely think it's a configuration issue.
Comment 7 Edward Z. Yang 2006-06-19 14:31:05 UTC
With the latest SVN version of both MediaWiki and ParserFunctions, I can say
that my installation consistently gives negative numbers.
Comment 8 Edward Z. Yang 2006-06-19 14:36:00 UTC
Created attachment 1989 [details]
Conditionally calls bcmath to fix bug if bcmath is installed
Comment 9 omniplex 2006-06-22 08:55:15 UTC
Interesting results, in other words any given either gets it always right or 
always wrong. The "intermittent" effect only caused by load balancing. What
is wrong with the serves always getting it wrong, why not fix that? Otherwise
I fear your fix doesn't help generally, Wikis offering arbitrary precision
math probably, that might be rare, who needs it?

Another approach could be to limit the input for MOD in a reliable way, if
the operands need more than 14 decimal digits just throw an error, always,
reliable. I'm not sure if 14 is correct, it could be also 13. Apparently not
15, although 64 bits IEEE can AFAIK represent all integers with 15 digits.

Comment 10 omniplex 2006-06-22 08:59:42 UTC
If anybody can decipher the gibberish I've typed above,
sorry. I'd need a textarea with 45 or less characters.
Comment 11 Brion Vibber 2006-06-22 09:34:33 UTC
32 vs 64-bit.
Comment 12 omniplex 2006-06-29 16:24:59 UTC
re #11, ACK, I just wanted to add the same info found in an online PHP manual
Comment 13 Sumana Harihareswara 2012-01-23 19:51:56 UTC
Edward, I'm sorry it has taken so very long for us to respond to this patch!  Would you kindly check whether it's still necessary and whether it still applies to trunk?  Thanks!
Comment 14 Bawolff (Brian Wolff) 2012-01-23 19:58:43 UTC
(In reply to comment #11)
> 32 vs 64-bit.

Given 6 years have past - is it safe to say that Wikimedia servers are all 64 bit, and hence this is no longer an issue?
Comment 15 Sam Reed (reedy) 2012-01-23 20:06:08 UTC
(In reply to comment #14)
> (In reply to comment #11)
> > 32 vs 64-bit.
> Given 6 years have past - is it safe to say that Wikimedia servers are all 64
> bit, and hence this is no longer an issue?

I'm fairly sure this is the case yeah, more so for the apaches
Comment 16 Platonides 2012-01-23 20:09:49 UTC
All our web servers are 64 bits now, so assuming this was fixed for 64bits php and/or new releases... Closing.

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