PHP 5.3.3 hangs on numeric value 2.2250738585072011e-308

Follow-up: PROBLEM SOLVED.<p>This problem occurs due to IA-32's 80-bit floating point arithmetic. The simple fix: add a "-ffloat-store" flag to your CFLAGS.<p>The problematic function, zend_strtod, seems to parse the mantissa (2.225...011 part) and the exponent (-308 part) separately, calculate the <i>approximation</i> of m*10^e and successively improve that approximation until the error becomes less than 0.5ulp. The problem is that this particular number causes the infinite loop (i.e. the iteration does not improve the error at all) in 80-bit FP, but does not in 64-bit FP. Since x86-64 in general uses the SSE2 instruction set (with 64-bit FP) instead of the deprecated x87 it does not have this problem.

<i>If you have any thoughts on what the bug is, please let me (or PHP) know.</i><p>Here's what you do. Step 1: compile PHP with debugging symbols. Then run the test case in GDB:<p><pre><code> $ gdb `which php` (gdb) set args testcase.php (gdb) run &#60;program hangs&#62; </code></pre> Then hit C-c, and see where the program is: ^C Program received signal SIGINT, Interrupt. 0x0000000000703898 in ?? ()<p><pre><code> #0 0x0000000000703898 in ?? () #1 0x00000000006aae40 in execute () #2 0x00007ffff4400116 in ?? () from /usr/lib/php5/20090626/suhosin.so #3 0x000000000068290d in zend_execute_scripts () #4 0x000000000062e1a8 in php_execute_script () #5 0x000000000071317a in ?? () #6 0x00007ffff5475c4d in __libc_start_main (main=&#60;value optimized out&#62;, argc=&#60;value optimized out&#62;, ubp_av=&#60;value optimized out&#62;, init=&#60;value optimized out&#62;, fini=&#60;value optimized out&#62;, rtld_fini=&#60;value optimized out&#62;, stack_end=0x7fffffffe9c8) at libc-start.c:228 #7 0x000000000042d4b9 in _start () </code></pre> Now you have some idea of where to look. (Note: this is not the actual bug, as I can't reproduce it on my machine. This is &#60;?php while(1){} ?&#62;, which is just as good for demonstration purposes. Also, no debugging symbols, so we don't really know what's going on.)<p>No offense, but this is like programming 101.

As the author said, it does hang in zend_strtod.c, and it seems to happen in 32-bit only.<p>Debug trace:<p><pre><code> #0 0x0832257f in mult (a=0xe1931e82, b=0x8781590) at /usr/src/php-5.3.3/Zend/zend_strtod.c:720 #1 0x08322757 in pow5mult (b=0x8781590, k=1) at /usr/src/php-5.3.3/Zend/zend_strtod.c:803 #2 0x08324443 in zend_strtod (s00=0xb7a7d01d "e-308;\n?&#62;\n", se=0x0) at /usr/src/php-5.3.3/Zend/zend_strtod.c:2352 #3 0x082e03ce in lex_scan (zendlval=0xbf94dd34, tsrm_ls=0x8648050) at Zend/zend_language_scanner.l:1382 #4 0x082fa849 in zendlex (zendlval=0xbf94dd30, tsrm_ls=0x8648050) at /usr/src/php-5.3.3/Zend/zend_compile.c:4942 #5 0x082dcc47 in zendparse (tsrm_ls=0x8648050) at /usr/src/php-5.3.3/Zend/zend_language_parser.c:3280 #6 0x082dd232 in compile_file (file_handle=0xbf9502d0, type=8, tsrm_ls=0x8648050) at Zend/zend_language_scanner.l:354 #7 0x081ad3cc in phar_compile_file (file_handle=0xbf9502d0, type=8, tsrm_ls=0x8648050) at /usr/src/php-5.3.3/ext/phar/phar.c:3393 #8 0x0830acc5 in zend_execute_scripts (type=8, tsrm_ls=0x8648050, retval=0x0, file_count=3) at /usr/src/php-5.3.3/Zend/zend.c:1186 #9 0x082b660f in php_execute_script (primary_file=0xbf9502d0, tsrm_ls=0x8648050) at /usr/src/php-5.3.3/main/main.c:2260 #10 0x08388893 in main (argc=2, argv=0xbf9503b4) at /usr/src/php-5.3.3/sapi/cli/php_cli.c:1192</code></pre>

Bug appearing at my Core 2 Duo / Win7 / PHP 5.3.0.<p>This is <i>really</i> serious. In fact, I’ve just tested if the problem happens for GET passed values and it does. Not all the passed data to a website is treated as a number, so not all websites with the PHP versions and configuration that could fail with this bug will be vulnerable, but definitely there is going to be a huge amount of websites that will do. This is really scaring.<p>I hope the PHP team patch it soon.<p>Meanwhile, a possible workaround would be adding this line at the very top of the execution of php website:<p>if (strpos(str_replace('.', '', serialize($GLOBALS)), '22250738585072011')!==false) die();<p>This will stop execution if any decimal version of the number were passed as parameter. Note that 222.50738585072011e-310 cause problems too, and any of the other possibilities to write it.<p>Do you know if there are any other possible ways to write the number that causes trouble too?

Some of my friends verified the case. Highlights:<p>- PHP 5.3.3-1ubuntu9.1 i686 build (built on Oct 15 2010 14:17:04) hits the bug.<p>- PHP 5.3.3-1ubuntu9.1 x86_64 build (built on Oct 15 2010 14:00:18) doesn't have the bug.<p>In the i686 build ltrace shows the memcpy call repeating infinitely, suggesting the bug originates from 32-bit and 64-bit problems.

Though the author doesn't seem to be malicious in any way, he really should have reported it to the PHP core team as a security vulnerability before writing a blog post. This could easily lead to denial-of-service attacks.

This must be it then:<p>do { z = (<i>x &#38; 0xffff) </i> y + (<i>xc &#62;&#62; 16) + carry; carry = z &#62;&#62; 16; Storeinc(xc, z, z2); z2 = (</i>x++ &#62;&#62; 16) * y + (*xc &#38; 0xffff) + carry; carry = z2 &#62;&#62; 16; } while(x &#60; xae);<p>Hit up gdb and watch xae and x...<p>I'll try myself but I don't have 32bit.

Rasmus Lerdorf just tweeted that it's a gcc optimizer issue:<p><pre><code> Works fine with -O0 but not -O2 </code></pre> <a href="http://twitter.com/rasmus/statuses/22212610308964353" rel="nofollow">http://twitter.com/rasmus/statuses/22212610308964353</a>

Doesn't hang for me:<p><pre><code> [1:26am:~/Downloads] RIDGELAND:root [0:16]# php -v PHP 5.3.3 (cli) (built: Aug 22 2010 19:41:55) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies</code></pre>

Can everybody who posts php -v (in as far as that is necessary...) also post uname -a, otherwise there's not much to go on...

<p><pre><code> %php -r 'print(2.225073858502011e-308+0);print("\n");' 2.225073858502E-308 %uname -a FreeBSD unknown 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 %php -v PHP 5.3.3 with Suhosin-Patch (cli) (built: Oct 17 2010 13:41:11) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH</code></pre>

I've fixed this now in all the PHP branches.<p><a href="http://svn.php.net/viewvc/?view=revision&#38;revision=307095" rel="nofollow">http://svn.php.net/viewvc/?view=revision&#38;revision=307095</a>

Check out the last lines for<p><pre><code> strace php p.php lstat64("/home/ubuntu/junk/p.php", {st_mode=S_IFREG|0644, st_size=59, ...}) = 0 lstat64("/home/ubuntu/junk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/home/ubuntu", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfe51238) = -1 ENOTTY (Inappropriate ioctl for device) fstat64(3, {st_mode=S_IFREG|0644, st_size=59, ...}) = 0 mmap2(NULL, 68, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb78d1000 </code></pre> The next thing that should be hapenning is munmap for that very same address, but something hangs...

I can't reproduce on CentOS:<p><pre><code> $ php -v PHP 5.2.6 (cli) (built: May 5 2008 10:32:59) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator $ uname -a Linux hostname 2.6.18-128.1.10.el5 #1 SMP Thu May 7 10:39:21 EDT 2009 i686 i686 i386 GNU/Linux</code></pre>

Awesome, this catches HostGator's PHP 5.3.3 (which isn't used by default, have to turn it on yourself) too. I knew there was yet another good reason for always casting expected-int input before doing anything with them... Something as simple as<p><pre><code> mysite.com/page/1 ===&#62; $page = 1 ===&#62; href="/page/' . $page + 1 . '"&#62;next page </code></pre> could mess you up...

I am confused. Does this only affect people with older cpus that do not support SSE2?<p>I am not affected by the bug, yet am on a 32 bit CPU and PHP 5.2.16 was compiled with -O2.<p>uname -a:<p>Linux www 2.6.9-67.0.22.ELsmp #1 SMP Fri Jul 11 10:38:12 EDT 2008 i686 i686 i386 GNU/Linux<p>Running the test script outlined above comes back immediately. No hang.<p>CPU is Intel(R) Xeon(R) CPU E5430 @ 2.66GHz which support SSE2.<p>Since my CPU supports SSE2, would I not be affected by this?

And so, the race after affected websites starts...

We have slapped together a quick workaround that can be found here:<p><a href="http://www.aircraft24.com/en/info/php-float-dos-quickfix.htm" rel="nofollow">http://www.aircraft24.com/en/info/php-float-dos-quickfix.htm</a><p>Its a quick+dirty fix for site-owners that cannot immediately upgrade php.

I can't reproduce.<p><pre><code> ubuntu@ip-10-130-57-139:~$ php -v PHP 5.3.3-1ubuntu9.1 with Suhosin-Patch (cli) (built: Oct 15 2010 14:00:18) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies</code></pre>

I can't reproduce under Debian:<p><pre><code> PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 4 2010 03:25:57) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies</code></pre>

Hangs with the php version installed with xampp 1.7.3 on Windows 7.<p>PHP 5.3.1 (cli) (built: Nov 20 2009 17:26:32) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

glaceon:~ $ php -r 'print(2.225073858502011e-308+0);print("\n");' 2.225073858502E-308<p>glaceon:~ $ php -v PHP 5.3.3 (cli) (built: Aug 22 2010 19:41:55) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies<p>glaceon:~ $ uname -a Darwin glaceon 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 i386

It does hang on my Ubuntu desktop:<p><pre><code> PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built: Sep 17 2010 13:41:55)</code></pre>

PHP Version 5.3.0 via a default WAMP install on Windows 7 hangs as well

Ouch, this hangs if PHP is run from the command line on Lucid Lynx.

Good advertisement in a way for more type safe languages, given I'm passing something as a string into JSON then using it as a string but PHP still converts it to a double which triggers this error.