Page MenuHomePhabricator

ParserFunctions MOD result sometimes wrong
Closed, ResolvedPublic


Author: omniplex

{{#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)

Version: unspecified
Severity: normal
Platform: Other



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:19 PM
bzimport added a project: ParserFunctions.
bzimport set Reference to bz6356.
bzimport added a subscriber: Unknown Object (MLST).

ezyang wrote:

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.

ezyang wrote:

This bug will probably be fixed if Bug 6068 is fixed, but this one can also be
fixed independently.

ezyang wrote:

Fixes bug by using bcmod(). Performance impact unknown.

attachment ExprModulus.patch ignored as obsolete

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.

ezyang wrote:

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

ezyang wrote:

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.

ezyang wrote:

With the latest SVN version of both MediaWiki and ParserFunctions, I can say
that my installation consistently gives negative numbers.

ezyang wrote:

Conditionally calls bcmath to fix bug if bcmath is installed


omniplex wrote:

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.

omniplex wrote:

If anybody can decipher the gibberish I've typed above,
sorry. I'd need a textarea with 45 or less characters.

omniplex wrote:

re #11, ACK, I just wanted to add the same info found in an online PHP manual

sumanah wrote:

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!

(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?

(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

All our web servers are 64 bits now, so assuming this was fixed for 64bits php and/or new releases... Closing.