PHP extensions: bcmath, calendar, com_dotnet, ctype, session, filter, ftp, hash, iconv, json, odbc, pcre, Reflection, date, libxml, standard, tokenizer, zlib, SimpleXML, dom, SPL, wddx, xml, xmlreader, xmlwriter, apache2handler, bz2, curl, dba, dbase, fdf, gd, gettext, gmp, imap, interbase, ldap, mbstring, mcrypt, mhash, mime_magic, ming, mysql, mysqli, openssl, PDO, PDO_Firebird, pdo_mysql, PDO_ODBC, pdo_sqlite, shmop, snmp, soap, sockets, SQLite, tidy, xmlrpc, xsl, zip, exif, xdebug Server modules: core, mod_win32, mpm_winnt, http_core, mod_so, mod_actions, mod_alias, mod_asis, mod_auth_basic, mod_authn_default, mod_authn_file, mod_authz_default, mod_authz_groupfile, mod_authz_host, mod_authz_user, mod_autoindex, mod_cgi, mod_deflate, mod_dir, mod_env, mod_expires, mod_include, mod_isapi, mod_mime, mod_negotiation, mod_rewrite, mod_setenvif, mod_php5 Operating system: Windows NT 6.0 build 6002 i586 (Windows Vista) This bug could have been avoided altogether if zend_strtod() was kept in sync with David Gay’s strtod() see my article “ A Better Fix for the PHP 2.2250738585072011e-308 Bug.” I’ve found the specific cause of the bug, and why the fix fixes it please see my article “ Why “Volatile” Fixes the 2.2250738585072011e-308 Bug.” Update: The Real Problem Is the Old Copy of dtoa.c Update: An Analysis of the Bug and Its Fix The problem is known to only affect x86 32-bit PHP processes, regardless of whether the system hosting PHP is 32-bit or 64-bit. This release resolves a critical issue … where conversions from string to double might cause the PHP interpreter to hang on systems using x87 FPU registers. The bug fix was released on this is from the PHP news release: It seems the only ones that cause a problem though are those whose 18th digit is 0, 1, 2, or 3 (2.22507385850720114e-308 doesn’t cause the problem, for example). In decimal these numbers are distinct, but they all map to the same floating-point number. : I thought of another set of numbers that cause the same problem - numbers of 18 digits or more but with the same 17 digit prefix. You can also alter the full 324 decimal place version of the number with leading and trailing zeros. : There is a lot of discussion about this, in addition to the comments below for example, seeĪnd as pointed out in the comments, equivalent forms of the number also cause the problem: I’ve gotten no response to my bug report yet, but I can’t help but wonder: is this serious? Could you bring down a Web server by entering this constant in a PHP-based form? Update If you have any thoughts on what the bug is, please let me (or PHP) know. It happens to be the largest of the five decimal values, so I guess that matters somehow. (Update: zend_strtod() is called, and I can hang zend_strtod() in Visual C++ if I compile with all optimizations.) What’s Special About 2.2250738585072011e-308?Ģ.2250738585072011e-308 represents the largest subnormal double-precision floating-point number written as a hexadecimal floating-point constant, it’s 0x0.fffffffffffffp-1022. I don’t know if zend_strtod() is even called in this case, but it was simple enough for me to isolate it and run it outside of PHP - under Visual C++ in fact. I found zend_strtod.c, which appears to be based on a very old version of David Gay’s strtod() function. I don’t have a debug build of PHP available, but I did poke around in the source code (version 5.2.8). I’ve written a bug report.Īs a string, 2.2250738585072011e-308 causes no problems it’s when it’s treated as a numeric value that the bug hits. I hit this bug in the two places I tested for it: on Windows (PHP 5.3.1 under XAMPP 1.7.3), and on Linux (PHP Version 5.3.2-1ubuntu4.5) - both on an Intel Core Duo processor. (The same thing happens if you write the number without scientific notation - 324 decimal places.) I stumbled upon a very strange bug in PHP this statement sends it into an infinite loop:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |