|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2010-03-26 00:36 UTC] codeslinger at compsalot dot com
Description: ------------ is math accuracy important? no I am not talking about round-off errors. I am talking about the fact that most of the time, php correctly says that 2+2 = 4, but that sometimes it says that 2+2 = 0. What if your paycheck was being printed by a php program and you discovered that the math is inaccurate, would you care then? I ask these questions because I previously reported this bug because it occurred in a billing system that I wrote, but nobody considered that bug important enough to pursue it. Too complex, too hard to reproduce. whatever. Well, I have now encountered this bug again, with a much simpler program. and this program demonstrates that math in php is completely and totally untrustworthy. Does anyone care that fundamental functionality is unreliable? What good is a programming language that can't do math? php passes trivial math tests just fine; it's only when you use it in complex real-world ways that it starts failing. No these aren't binary base conversion errors, I'm guessing that this is memory corruption, so far I've only observed it with thousands of calculations. But the trivial programs I wrote in an attempt to reproduce the problem never succeeded in failing. I can only get it to fail when I'm doing real-world / complex stuff Characteristics: This is not a bug in the php program; under specific conditions - described below - the php program does run correctly. The main problem occurs when a float is converted to a string by a program that makes heavy use of arrays. It's not an out of memory condition, I have successfully stress tested an array with one million items, but I am seeing it fail with only a thousand items. When it fails, the failure it totally repeatable, it always fails in exactly the same place in exactly the same way. And yet there is no discernible pattern to the failure, the trigger condition is unpredictable, it seems to depend on the actual data values. It is not a hardware issue, this has been observed on multiple machines. Also my main computer has had extensive memory diagnostic and hard disk tests run on it without finding any problems. It is not operating system specific, this failure has been observed on both Linux and Windows. It is not an FDIV bug. This Pentium chip is verified to not have that bug. Different versions of php are triggered by different sequences of events. But all of them fail in some way. I have two programs, both of which fail, but the specifics of the failure vary depending on which version of php they are being run on. One program is a billing system, it is large and complex and proprietary and the data is confidential and it uses several external libraries. The other program generates a Koch Snowflake (a type of graphics fractal). It is small and has no required dependencies and I am happy to make it's source code available. Both fail with the same or similar math errors but the behavior is not identical. The billing system *appears* to run fine on Windows PHP 5.2.5 (standard build as provided by php.net). The billing system is in daily use and no errors have been reported... so far... At one point it was decided to upgrade to PHP 5.2.9 (standard build from php.net). The billing system passed the preliminary testing with dummy data and the php upgrade was deployed to the field. Result: Can you spell NIGHTMARE?!!! I knew you could... Many instances of invalid statements being created. The math errors were repeatable. We are talking simple arithmetic about 90 percent of it is just adding, with a few multiplications. This was entered as bug #47716 Everyone was downgraded back to php 5.2.5 and the bug report was blown off. I also confirmed that the bug existed in 5.2.11 I assumed that the bug did not exist in 5.2.5 An attempt was made to test 3.x but that was impossible because the billing system requires various libraries which are not available for version 3 of php. And that is where things have sat until now. New program, Koch Snowflake generator. I'm doing some experiments with 3d graphics. This was written as a study in how to do it. I ran into exactly the same math -- string conversion bug, that the billing system ran into. But the Koch Snowflake program Fails on Ubuntu Linux with php 5.2.4!!! What triggers this bug is a very complex unpredictable sequence of events. And yet the failure is totally repeatable. Being a fractal, it has an outer loop of iterations which determine the complexity of the object. When I run 4 outer loops the program works fine, when I run 6 outer loops the program also works fine -- thus proving that it is not running out of memory. But when I run 5 outer loops the program fails and it always fails at item 7747. But wait there is more. Because when I run the Koch program on php 5.2.9 on Linux, it does not fail with the string conversion error. What this tells me is that my assumption was wrong, this bug does exist in version 5.2.5 and that my billing system is sitting on a ticking bomb for which the actual trigger is unpredictable. And that is why I am trying to get someone, anyone, to please pay attention to this bug. It is very very very serious. If this bug is not fixed I am going to have to abandon php altogether. The stock answer that people should upgrade php as the solution to all of their problems fails to take into account real-world realities. When the day comes that you can get all of the libraries to upgrade, and when you can get all of the hosting providers to upgrade and you can get most of the Linux distros to upgrade. Then, on that day, you can indeed expect that people should use a newer version of php as the solution to their problems. I would indeed love to be able to run a more current version of php, but as long as I am dependent on certain libraries and I must lease services from various hosting providers I am constrained by what is actually available in the real-world. And currently what is the most widely deployed version in the real-world is 5.2.4. Besides which, as far as I can tell, this bug exists in all versions of php since at least 5.2.4. I see no indication of it ever having been fixed in any version of php. But the difficulty is that the behavior does change, the specific trigger sequence does change depending on which version of php is being used. Someone really needs to track down the actual cause of this problem in a version that can reliably reproduce the failure and not make assumptions that it does not exist in other versions just because it was not triggered. Test script: --------------- here is a url to the Koch snowflake program http://www.compsalot.com/phpbug/kochsnowflake/ see the source code for details of how to run the program. Please keep in mind that triggering this bug is very finicky. The billing program fails in 5.2.9 and 5.2.11 and works in 5.2.5 but the snowflake program works in 5.2.9 and fails in 5.2.4... The bug is in all of these versions but triggering it is difficult. I only tested the snowflake program on Ubuntu version 8 using both the standard 5.2.4 and also a self installed 5.2.9 on Ubuntu 8. Expected result: ---------------- float 0.1 becomes string "0.1" or close to it in the case of binary conversion issues. Actual result: -------------- The BUG: The problem is that when php performs thousands of floating point operations, at some point corruption occurs and the floating point numbers get coerced into an invalid string format. For example: (float) 0.1 becomes: (string) (string:4) 0.0: note the colon, that colon is part of the corruption. A floating point number is being turned into a string containing a colon. How is that possible??? PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Sat Dec 21 14:01:32 2024 UTC |
String conversion errors There is a flag called $FloatType You can use it to select the type of conversion that is done. //this fails with string conversion error case 0: $s = (string)$f; //this fails with string conversion error case 12: $s = is_float($f) ? sprintf('%.12F', $f) : (string)$f; //this fails with string conversion error case 14: $s = is_float($f) ? sprintf('%.14F', $f) : (string)$f; //this WORKS, does not cause a string conversion error case 20: $s = is_float($f) ? sprintf('%.20F', $f) : (string)$f; When I say conversion error, I mean that the result is "0.0:" not that php gives any kind of error message.The billing program was failing on multiple computers at multiple locations, it failed on XP and Windows 2000 with various cpus. Those were customer sites! I reproduced the problem on a vmware setup with windows 2000. This snowflake program is failing on Ubuntu Hardy 8.0.4 with all of the updates. This is the stock php that comes with Ubuntu. This is a Pentium M 32bit Laptop. I've never experienced a memory error on this computer and the fact of it's consistency would argue against this being some kind of hardware issue. Here is what I get when I run the simplefail in the default config. 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 ========== php simplefail.php Selected onepair.txt, Found 1 items (string)(double) -0.1 === -0.1 which of course is correct But when we convert the value in an array it fails Conversion Error: PHP Math idx = 0 || '-0.1' !== '-0.0:' ===== THANK YOU I REALLY APPRECIATE THE HELPYou 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.This problem isn't fixed for us by adding "ini_set("precision", 16);". Our PHP install is stock off the website (5.2.4 and 5.2.13, for instance) and our box runs Windows 2003.<?php ini_set("precision",16); echo (string) (double) -0.09; echo "\n"; echo (string) (double) -0.099; echo "\n"; echo (string) (double) -0.0999; echo "\n"; echo (string) (double) -0.09999; echo "\n"; echo (string) (double) -0.099999; echo "\n"; echo (string) (double) -0.0999999; echo "\n"; echo (string) (double) -0.09999999; echo "\n"; echo (string) (double) -0.099999999; echo "\n"; echo (string) (double) -0.0999999999; echo "\n"; echo (string) (double) -0.09999999999; echo "\n"; echo (string) (double) -0.099999999999; echo "\n"; echo (string) (double) -0.0999999999999; echo "\n"; echo (string) (double) -0.09999999999999; echo "\n"; echo (string) (double) -0.099999999999999; echo "\n"; echo (string) (double) -0.0999999999999999; echo "\n"; echo (string) (double) -0.09999999999999999; echo "\n"; echo (string) (double) -0.099999999999999999; echo "\n"; echo (string) (double) -0.0999999999999999999; echo "\n"; echo (string) (double) -0.09999999999999999999; echo "\n"; echo (string) (double) -0.099999999999999999999; echo "\n"; echo (string) (double) -0.0999999999999999999999; echo "\n"; /* Seems like something is still broken: php test.php -0.09 -0.099 -0.0999 -0.09999 -0.099999 -0.0999999 -0.09999999 -0.09999999900000001 -0.0999999999 -0.09999999999 -0.099999999999 -0.0999999999999 -0.09999999999999 -0.09999999999999901 -0.09999999999999989 -0.09999999999999999 -0.1 -0.1 -0.1 -0.1 -0.1 */ ?><?php /* This one is better */ ini_set("precision",17); /* changed precision from 16 to 17 */ echo (string) (double) -0.09; echo "\n"; echo (string) (double) -0.099; echo "\n"; echo (string) (double) -0.0999; echo "\n"; echo (string) (double) -0.09999; echo "\n"; echo (string) (double) -0.099999; echo "\n"; echo (string) (double) -0.0999999; echo "\n"; echo (string) (double) -0.09999999; echo "\n"; echo (string) (double) -0.099999999; echo "\n"; echo (string) (double) -0.0999999999; echo "\n"; echo (string) (double) -0.09999999999; echo "\n"; echo (string) (double) -0.099999999999; echo "\n"; echo (string) (double) -0.0999999999999; echo "\n"; echo (string) (double) -0.09999999999999; echo "\n"; echo (string) (double) -0.099999999999999; echo "\n"; echo (string) (double) -0.0999999999999999; echo "\n"; echo (string) (double) -0.09999999999999999; echo "\n"; echo (string) (double) -0.099999999999999999; echo "\n"; echo (string) (double) -0.0999999999999999999; echo "\n"; echo (string) (double) -0.09999999999999999999; echo "\n"; echo (string) (double) -0.099999999999999999999; echo "\n"; echo (string) (double) -0.0999999999999999999999; echo "\n"; /* Seems like something is still broken: php --version PHP 5.5.35-pl0-gentoo (cli) (built: May 13 2016 22:17:08) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies php test.php -0.089999999999999997 -0.099000000000000005 -0.099900000000000003 -0.099989999999999996 -0.099999000000000005 -0.099999900000000003 -0.099999989999999997 -0.099999999000000006 -0.099999999899999997 -0.099999999990000005 -0.099999999999 -0.099999999999900002 -0.09999999999999 -0.099999999999999006 -0.099999999999999895 -0.099999999999999992 -0.10000000000000001 -0.10000000000000001 -0.10000000000000001 -0.10000000000000001 -0.10000000000000001 */ ?>