Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=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
Bug #51396 [Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Updated by: paj...@php.net 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: There is no need to write a novel about this possible issue. Please ask the Mandriva guys to actually report a bug here (in this report for example), post their patch(es), a reproduce script with a description of their architecture (compiler, compiler versions, OS, etc.). Everything else are unnecessary information. Now, what Johannes said is still valid: - we don't support custom version of PHP (aka patched) - that includes suhoshin patch - Debugger/optimizer (zend, xdebug, etc.) has to be removed to reproduce a problem. Thanks for your feedback. Previous Comments: [2010-05-23 09:38:47] codeslinger at compsalot dot com 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, ;-) [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
[PHP-BUG] Bug #51892 [NEW]: preg_match_all forces the use of a $matches variable
From: Operating system: Linux PHP version: 5.2.13 Package: *General Issues Bug Type: Bug Bug description:preg_match_all forces the use of a $matches variable Description: If you use preg_match_all and are only interested in the return value (i.e. you are not interested in the data stored in $matches) you are still forced to declare a variable for $matches. I'm not sure if this is a bug in preg_match_all or in php's passed_by_reference. My first thought was to pipe $matches to a php-equivalent of /dev/null, but something like that doesn't exist to my knowledge. -- Edit bug report at http://bugs.php.net/bug.php?id=51892edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51892r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51892r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51892r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51892r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51892r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51892r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51892r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51892r=needscript Try newer version: http://bugs.php.net/fix.php?id=51892r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51892r=support Expected behavior: http://bugs.php.net/fix.php?id=51892r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51892r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51892r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51892r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51892r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51892r=dst IIS Stability: http://bugs.php.net/fix.php?id=51892r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51892r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51892r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51892r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51892r=mysqlcfg
Bug #51892 [Opn-Bgs]: preg_match_all forces the use of a $matches variable
Edit report at http://bugs.php.net/bug.php?id=51892edit=1 ID: 51892 Updated by: degeb...@php.net Reported by: hugo at ankarloo dot nu Summary: preg_match_all forces the use of a $matches variable -Status: Open +Status: Bogus Type: Bug Package: *General Issues Operating System: Linux PHP Version: 5.2.13 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Use preg_match(). http://php.net/preg_match Previous Comments: [2010-05-23 17:42:34] hugo at ankarloo dot nu Description: If you use preg_match_all and are only interested in the return value (i.e. you are not interested in the data stored in $matches) you are still forced to declare a variable for $matches. I'm not sure if this is a bug in preg_match_all or in php's passed_by_reference. My first thought was to pipe $matches to a php-equivalent of /dev/null, but something like that doesn't exist to my knowledge. -- Edit this bug report at http://bugs.php.net/bug.php?id=51892edit=1
Bug #51889 [Opn-Fbk]: go-pear will fail, miserably
Edit report at http://bugs.php.net/bug.php?id=51889edit=1 ID: 51889 Updated by: ka...@php.net Reported by: dmda at yandex dot ru Summary: go-pear will fail, miserably -Status: Open +Status: Feedback Type: Bug Package: PHAR related Operating System: Win32 PHP Version: 5.3.2 New Comment: Try open go-pear.bat and find this line: %PHP_BIN% -d output_buffering=0 PEAR\go-pear.phar and change it do: %PHP_BIN% -d output_buffering=0 -d phar.require_hash=0 PEAR\go-pear.phar Previous Comments: [2010-05-22 22:38:48] dmda at yandex dot ru Description: go-pear.bat throws warnings and errors. C:\php5go-pear.bat phar C:\php5\PEAR\go-pear.phar does not have a signature Warning: require_once(phar://go-pear.phar/index.php): failed to open stream: pha r error: invalid url or non-existent phar phar://go-pear.phar/index.php in C:\ php5\PEAR\go-pear.phar on line 1236 Press any key to continue . . . -- Edit this bug report at http://bugs.php.net/bug.php?id=51889edit=1
[PHP-BUG] Bug #51894 [NEW]: DateTime::Diff breaks range()
From:
Operating system: Windows 7 Home Premium 64bit
PHP version: 5.3.2
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::Diff breaks range()
Description:
After calling DateTime::Diff() the first call to range() fails and issues a
warning.
Test script:
---
date_default_timezone_set('Europe/Paris');
$dt = new DateTime('2010-10-10');
$dt-diff(new DateTime('2010-12-12'));
range(0,-1,1);
Expected result:
array(2) { [0]= int(0) [1]= int(-1) }
Actual result:
--
Warning: range(): step exceeds the specified range
bool(false)
--
Edit bug report at http://bugs.php.net/bug.php?id=51894edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51894r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51894r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51894r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51894r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51894r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51894r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51894r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51894r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51894r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51894r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51894r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51894r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51894r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51894r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51894r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51894r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51894r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51894r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51894r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51894r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51894r=mysqlcfg
Bug #47412 [Opn-Asn]: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
Edit report at http://bugs.php.net/bug.php?id=47412edit=1
ID: 47412
Updated by: fel...@php.net
Reported by: tser at deltacontrols dot com
Summary: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
-Status: Open
+Status: Assigned
Type: Bug
Package: CGI related
Operating System: win32 only - Vista
PHP Version: 5.2.9RC2
Assigned To: pajoye
Previous Comments:
[2010-05-13 21:29:39] tser at deltacontrols dot com
Using Vista64 IIS7 with the update (KB980363).
1. Setup PHP FactCGI in IIS. Everything default.
2. Open C:\Windows\System32\inetsrv\config\applicationHost.config
Edit the fastCgi section and add signalBeforeTerminateSeconds=30
fastCgi
application fullPath=C:\Program Files
(x86)\PHP\php-cgi.exe maxInstances=2 idleTimeout=30001
activityTimeout=3000 instanceMaxRequests=1
signalBeforeTerminateSeconds=30
environmentVariables
environmentVariable name=PHP_FCGI_MAX_REQUESTS
value=1 /
environmentVariable name=PHPRC value=C:\Program
Files (x86)\PHP\ /
/environmentVariables
/application
/fastCgi
3. Create a test.php with ?phpinfo();?. Browse it.
4. Attach debugger to php-cgi.exe process (with debug symbol).
5. Put a breakpoint in sapi/cgi/fastcgi.c (after WaitForSingleObject)
static DWORD WINAPI fcgi_shutdown_thread(LPVOID arg)
{
HANDLE shutdown_event = (HANDLE) arg;
WaitForSingleObject(shutdown_event, INFINITE);
in_shutdown = 1; --breakpoint here
return 0;
}
6. Put a break point in ext/date/php_date.c
PHP_MSHUTDOWN_FUNCTION(date)
{
UNREGISTER_INI_ENTRIES();
return SUCCESS; breakpoint here
}
7. Open a command prompt and do a iisreset.
Notice that the breakpoint in fcgi_shutdown_thread will get hit but the
PHP_MSHUTDOWN_FUNCTION(date) function is not being called.
Before the IIS updates, FastCGI module always force kill php-cgi.exe,
make it impossible for php-cgi.exe to properly call
PHP_MSHUTDOWN_FUNCTION for each extension.
With the new setting signalBeforeTerminateSeconds,
_FCGI_SHUTDOWN_EVENT_ will be triggered to give php-cgi.exe a change
to do proper cleanup. There are actually code in fastcgi.c (PHP) to wait
for that event. However, it still does not properly call
PHP_MSHUTDOWN_FUNCTION for all the loaded extension.
[2010-05-13 21:03:18] paj...@php.net
Please post the relevant information here ( feedback again).
[2010-05-13 20:27:26] tser at deltacontrols dot com
I cannot re-open the bug.
There are more info on handling of SignalBeforeTerminateSeconds
Please refer to http://forums.iis.net/t/1167753.aspx
[2010-05-12 02:12:15] tser at deltacontrols dot com
More information.
Using the latest FastCGI update on IIS7 (KB980363) which support
SignalBeforeTerminateSeconds, PHP_MSHUTDOWN_FUNCTION is still not being
called.
Look into the code in sapi/cgi/fastcgi.c
A thread fcgi_shutdown_thread has been created to trap the
_FCGI_SHUTDOWN_EVENT_
event but the code simply set in_shutdown to 1. After that,
PHP_MSHUTDOWN_FUNCTION
in the extension code is still not being called.
[2010-01-12 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
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=47412
--
Edit this bug report at http://bugs.php.net/bug.php?id=47412edit=1
[PHP-BUG] Bug #51896 [NEW]: class a {function __construct(){new a();}} new a(); # - kills php
From:
Operating system: Windows XP
PHP version: 5.3SVN-2010-05-23 (SVN)
Package: Reproducible crash
Bug Type: Bug
Bug description:class a {function __construct(){new a();}} new a(); # - kills
php
Description:
I know it's wrong to try to instantiate a class within it's own
constructor,
yet I thought that I should report the crashing of the php interpreter.
Perhaps this case may expose an area of the interpreter that may cause
other problems.
Here is a sample script.
?php class a {function __construct(){new a();}} new a(); # - kills php ?
Here is the message produced (with php 5.3.2):
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 261904 bytes) in M:\workspace\html\directAbrasives\lib\t.php on
line 1
Here is my php version:
PHP 5.3.2 (cli) (built: Mar 3 2010 20:47:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Running this code on PHP 5.2 didn't generate any message at all.
Also, I tried a catching exceptions, yet it appears that none are thrown in
this case.
I am operating on WindowsXP.
Cheers.
-g
Test script:
---
?php class a {function __construct(){new a();}} new a(); # - kills php ?
Expected result:
Some kind of error message with a line number saying you can't do this.
Actual result:
--
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 261904 bytes) in M:\workspace\html\directAbrasives\lib\t.php on
line 1
--
Edit bug report at http://bugs.php.net/bug.php?id=51896edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51896r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51896r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51896r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51896r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51896r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51896r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51896r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51896r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51896r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51896r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51896r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51896r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51896r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51896r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51896r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51896r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51896r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51896r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51896r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51896r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51896r=mysqlcfg
Bug #51896 [Opn-Bgs]: class a {function __construct(){new a();}} new a(); # - kills php
Edit report at http://bugs.php.net/bug.php?id=51896edit=1
ID: 51896
Updated by: fel...@php.net
Reported by: RocketInABog at techno-monks dot net
Summary: class a {function __construct(){new a();}} new a(); #
- kills php
-Status: Open
+Status: Bogus
Type: Bug
Package: Reproducible crash
Operating System: Windows XP
PHP Version: 5.3SVN-2010-05-23 (SVN)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2010-05-24 00:32:45] RocketInABog at techno-monks dot net
Description:
I know it's wrong to try to instantiate a class within it's own
constructor,
yet I thought that I should report the crashing of the php interpreter.
Perhaps this case may expose an area of the interpreter that may cause
other problems.
Here is a sample script.
?php class a {function __construct(){new a();}} new a(); # - kills php
?
Here is the message produced (with php 5.3.2):
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 261904 bytes) in M:\workspace\html\directAbrasives\lib\t.php on
line 1
Here is my php version:
PHP 5.3.2 (cli) (built: Mar 3 2010 20:47:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Running this code on PHP 5.2 didn't generate any message at all.
Also, I tried a catching exceptions, yet it appears that none are thrown
in this case.
I am operating on WindowsXP.
Cheers.
-g
Test script:
---
?php class a {function __construct(){new a();}} new a(); # - kills php
?
Expected result:
Some kind of error message with a line number saying you can't do this.
Actual result:
--
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 261904 bytes) in M:\workspace\html\directAbrasives\lib\t.php on
line 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51896edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=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: Yipee!!! at least I have finally found a work-around that I can live with!!! You can close this bug now. The Mandriva Devs seem to think that this is actually a GCC bug and that it is Dependant on the build flags used. You can read about it here. https://qa.mandriva.com/show_bug.cgi?id=37171 Thanks to John (above) for the link. A lot more reading/searching of this WELL KNOWN ISSUE finally lead me to here: http://www.mysqlperformanceblog.com/2008/01/10/php-vs-bigint-vs-float-conversion-caveat/ and here: http://www.farad.com.au/source_code/php/setting_floating_point_precision_src.php To cut to the chase, the actual work-around is to change the precision. This solution was hinted at by my simplefail.php program (test option 20), but I was unaware of an ini setting that is available for this. The solution to all of this madness and it is very mad indeed... is to add the following in your php program. ini_set(precision, 16); End of Problem End of Bug... Like Good Day Eh? Previous Comments: [2010-05-23 14:42:13] paj...@php.net There is no need to write a novel about this possible issue. Please ask the Mandriva guys to actually report a bug here (in this report for example), post their patch(es), a reproduce script with a description of their architecture (compiler, compiler versions, OS, etc.). Everything else are unnecessary information. Now, what Johannes said is still valid: - we don't support custom version of PHP (aka patched) - that includes suhoshin patch - Debugger/optimizer (zend, xdebug, etc.) has to be removed to reproduce a problem. Thanks for your feedback. [2010-05-23 09:38:47] codeslinger at compsalot dot com 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, ;-) [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:
Bug #51396 [Fbk-Bgs]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Updated by: paj...@php.net Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable -Status: Feedback +Status: Bogus Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: . Previous Comments: [2010-05-24 02:04:27] codeslinger at compsalot dot com Yipee!!! at least I have finally found a work-around that I can live with!!! You can close this bug now. The Mandriva Devs seem to think that this is actually a GCC bug and that it is Dependant on the build flags used. You can read about it here. https://qa.mandriva.com/show_bug.cgi?id=37171 Thanks to John (above) for the link. A lot more reading/searching of this WELL KNOWN ISSUE finally lead me to here: http://www.mysqlperformanceblog.com/2008/01/10/php-vs-bigint-vs-float-conversion-caveat/ and here: http://www.farad.com.au/source_code/php/setting_floating_point_precision_src.php To cut to the chase, the actual work-around is to change the precision. This solution was hinted at by my simplefail.php program (test option 20), but I was unaware of an ini setting that is available for this. The solution to all of this madness and it is very mad indeed... is to add the following in your php program. ini_set(precision, 16); End of Problem End of Bug... Like Good Day Eh? [2010-05-23 14:42:13] paj...@php.net There is no need to write a novel about this possible issue. Please ask the Mandriva guys to actually report a bug here (in this report for example), post their patch(es), a reproduce script with a description of their architecture (compiler, compiler versions, OS, etc.). Everything else are unnecessary information. Now, what Johannes said is still valid: - we don't support custom version of PHP (aka patched) - that includes suhoshin patch - Debugger/optimizer (zend, xdebug, etc.) has to be removed to reproduce a problem. Thanks for your feedback. [2010-05-23 09:38:47] codeslinger at compsalot dot com 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, ;-) [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
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: john dot smith dot 1964 at gmail dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Bogus Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: 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. Previous Comments: [2010-05-24 02:18:46] paj...@php.net . [2010-05-24 02:04:27] codeslinger at compsalot dot com Yipee!!! at least I have finally found a work-around that I can live with!!! You can close this bug now. The Mandriva Devs seem to think that this is actually a GCC bug and that it is Dependant on the build flags used. You can read about it here. https://qa.mandriva.com/show_bug.cgi?id=37171 Thanks to John (above) for the link. A lot more reading/searching of this WELL KNOWN ISSUE finally lead me to here: http://www.mysqlperformanceblog.com/2008/01/10/php-vs-bigint-vs-float-conversion-caveat/ and here: http://www.farad.com.au/source_code/php/setting_floating_point_precision_src.php To cut to the chase, the actual work-around is to change the precision. This solution was hinted at by my simplefail.php program (test option 20), but I was unaware of an ini setting that is available for this. The solution to all of this madness and it is very mad indeed... is to add the following in your php program. ini_set(precision, 16); End of Problem End of Bug... Like Good Day Eh? [2010-05-23 14:42:13] paj...@php.net There is no need to write a novel about this possible issue. Please ask the Mandriva guys to actually report a bug here (in this report for example), post their patch(es), a reproduce script with a description of their architecture (compiler, compiler versions, OS, etc.). Everything else are unnecessary information. Now, what Johannes said is still valid: - we don't support custom version of PHP (aka patched) - that includes suhoshin patch - Debugger/optimizer (zend, xdebug, etc.) has to be removed to reproduce a problem. Thanks for your feedback. [2010-05-23 09:38:47] codeslinger at compsalot dot com 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
