Edit report at http://bugs.php.net/bug.php?id=51396&edit=1
ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: In response to johan...@php.net above..... Let me just very politely reiterate that I originally encountered this bug on the STOCK WINDOWS BUILD from php.net, therefore to dismiss this bug because it is ubuntu specific is not a valid reason. This bug is very hard to reproduce, but none-the-less occurs far too frequently under real-world conditions. The actual values required to reproduce this bug appear to vary depending on what version of php is being tested and what os/cpu it is running on. Given the randomly variant nature of this problem, I suspect that the only way you could properly test this bug and have confidence in the outcome is if you loop through every possible floating point value and convert it to a string. You would also need to do this on multiple platforms. Of course that would probably take a few years... so perhaps code inspection and some alerts would be a better option. Testing numbers selected at random is not likely to succeed, the number space is too large and you can't account for possible biases in the random number generator -- perhaps it only returns numbers which php sees as valid. Other people have reported this bug, see for instance #49764 and also the above comments about Mandriva Devs creating a patch to fix this bug. I do not regard millions of Ubuntu users as unimportant, or irrelevant. The severity of the consequences of this bug ought to be sufficient justification for a little bit of extra effort being expended -- even if the problem had been caused by ubuntu patches which it wasn't. People who are affected by this bug may not always realize what the problem is. This bug is probably underreported by quite a bit. Also as pointed out earlier the majority of php web pages do not do very much floating point math and therefore would not encounter this bug. In the discussion above it appears that there is some obscure case for which the number conversion is off-by-one. Pajoye thinks he has a fix. The fact that this afflicts Financial Transactions -- as reported by multiple people -- makes this a gravely serious bug... so why then is it so exasperatingly difficult to get the php dev community to take this problem seriously? In case you are wondering why it took me so long to respond to Johannes, it's because I had to cool off first.... I really am trying not to be overwrought, honest, ;-) Previous Comments: ------------------------------------------------------------------------ [2010-04-14 04:37:08] john dot smith dot 1964 at gmail dot com The folk at Mandriva saw the same problem, figured it out and submitted a patch to PHP. I'm confused, because we're certainly still seeing the problem: https://qa.mandriva.com/show_bug.cgi?id=37171 "In PHP on Mandriva 2008, some float to string conversions return "0.0:" !! In critical software, this can lead to major loss of data or inconsistant results." ------------------------------------------------------------------------ [2010-04-13 03:36:47] john dot smith dot 1964 at gmail dot com I am seeing this bug consistently on standard Windows builds such as 5.2.4 and 5.2.13. Our Server is: Windows NT 5.2 build 3790 Sample code is simple: <? echo round(1451,2); ?> On 5.2.4 it will result in "1450.:0" every time. On 5.2.4, other such *funny* values are 1701,1821,1951,2091,2101,2111,2121,2341,2351... On 5.2.13,the numbers 1700 and 1900 consistently return "colon-ized" results. This is a especially problematic, because 1700 and 1900 occur more frequently in our eCommerce app! This issue is a real problem for us. It has been touched on (but not solved) in at least Bugs 46376, 47716, 47304 and 47418. ------------------------------------------------------------------------ [2010-03-27 14:19:44] johan...@php.net You are mentioned this version information: php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies This version is very different from the versions we provide. a) Ubuntu adds some custom patches b) Suhosin does major changes to the engine c) Xdebug as well as Zend Debugger do changes to our executor unit. All these components aren't supported here. ------------------------------------------------------------------------ [2010-03-27 12:50:58] codeslinger at compsalot dot com One further note, in the repro above, it has to be exactly 16 nines. by adding or removing a 9, it does not fail. Also, as far as I know, all of the failures have been on 32bit Intel cpu's. This probably will not fail on a 64bit cpu. ------------------------------------------------------------------------ [2010-03-27 12:22:12] codeslinger at compsalot dot com well, it's hard to prove a negative. but I have run a bunch of tests on the Linux snapshot and it appears to be working fine. A VERY BIG THANKYOU I did not find any windows snapshots, the latest is 5.2.13 from Feb 24. based on the symptoms, my initial assumption was that this was caused by some kind of array corruption, this turned out to be wrong. the actual repro can be boiled down to one line... :-) echo (string) (double) -0.09999999999999999; With the caveat that there are other values which also trigger this. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
