PHP updated to fix serious bug. Have you updated?

Portal Home > Knowledgebase > Articles Database > PHP updated to fix serious bug. Have you updated?

Posted by User is Admin, 01-07-2011, 08:33 AM
PHP.net has a new version now which fixes a critical bug. This bug can cause PHO to hand on a particular numeric value. More information here PHP people say it's a "Critical" so you must update your PHP. Here is the test script to test your server against this bug. From PHP.net If you host has not updated,remind them now or if you are a host with older PHP version,an upgrade is recommended.
Posted by 1Ago, 01-07-2011, 09:04 AM
Updated last night. Didn't seem to be affected by the bug though. Better to be safe than sorry.
Posted by jasonberke, 01-07-2011, 12:41 PM
Thanks for the information about php update. I was under the impression that PHP is the most stable and secure server side language out there. Anyhow, this does not seems to be a thing to worry for the majority of web applications & php developers.
Posted by MikeDVB, 01-07-2011, 01:08 PM
No matter what system is used, there are always going to be bugs, flaws, and exploits that need patched. Programming platforms are a products of humans and as such are flawed by nature.
Posted by tumbano, 01-07-2011, 01:23 PM
It doesn't seem to be available on easyapache btw... Will wait a couple days
Posted by Hostify Networks, 01-07-2011, 03:56 PM
My version of PHP is compiled as 64-bit, so I suppose there's not much for me to worry about. I would update to the latest version, but eaccelerator doesn't seem to agree with anything greater than 5.3.3...
Posted by 1Ago, 01-07-2011, 03:59 PM
The latest version of eAccelerator (v0.9.6.1) does work with PHP 5.3.5.
Posted by VSMinc, 01-07-2011, 04:17 PM
Is the new version of PHP 64bit compliant?
Posted by Hostify Networks, 01-07-2011, 04:31 PM
It didn't work so well the last time I tried. I got an error log full of stuff like this and of course non-working pages. I haven't taken the time to investigate what was going wrong. It could very well be my own coding error (but then I wouldn't expect it to work perfectly on one version and not at all on another). Here's a sample of the code from info.php:
Posted by petteyg359, 01-07-2011, 04:40 PM
There is no such thing as "64-bit compliant". What are you asking?
Posted by VSMinc, 01-07-2011, 04:58 PM
I am asking if it will compile to 64 bit, but reading the other posts, it seems it will be OK
Posted by petteyg359, 01-07-2011, 08:37 PM
64-bit OS has been supported at least since 4.0.0, not sure where you got the idea there would be problems...
Posted by josephgarbett, 01-08-2011, 08:07 AM
Exactly... Thats why security companies make soo much money. Although they do provide a valuable service, its mainly because of the probability of a 'Missing Bit' in the structure of a programming language.
Posted by aeris, 01-08-2011, 10:28 AM
This isn't so much a bug in PHP as it is a bug in GCC, and it is not so much a bug in GCC as it is a bug in the x87 FPU architecture. But I guess now everyone who switched back to 32-bit PHP after the last issue only affected 64-bit systems will be switching back.
Posted by travolta, 01-08-2011, 11:29 PM
Just started the updated, thank you for the info.
Posted by Daniel15, 01-09-2011, 12:31 AM
Give cPanel a week or two, they're incredibly slow with EasyApache updates. They do so much testing with it, which is okay, but it slows down releases heaps. People still use eAccelerator? I'd personally suggest to switch to something like APC or XCache. XCache is my personal favourite, but APC is also quite good. Both work with the latest PHP versions.
Posted by larwilliams, 01-11-2011, 05:23 PM
Neither of those compress the data they cache, which makes eAccelerator much better for anyone who needs to cache a great number of scripts.
Posted by petteyg359, 01-11-2011, 06:57 PM
That depends on how much CPU time you're adding by compressing and de-compressing, and whether it negates the speed benefit of caching. Also, if you have so many scripts on one cache mechanism that you're running out of memory, you're doing something horribly wrong.
Posted by larwilliams, 01-11-2011, 07:16 PM
From our experience, the CPU time is negligible. If you are using caching on shared hosting servers, you have no control over how many possible scripts can be cached. So the best performance overall is likely from a 1gb compressed cache vs a 1gb uncompressed cache.
Posted by tim2718281, 01-11-2011, 08:51 PM
Well, it could be used by someone wanting to make a web server hang - just enter the magic number, or one of its variants, into a numeric form field. Depending on the program, it might hang.
Posted by petteyg359, 01-11-2011, 09:22 PM
Use FPM, run multiple pools, and each can have its own cache.
Posted by skywin, 01-11-2011, 09:58 PM
Last build of EasyApache (5291) has patched all versions of PHP5.x. You only need run again and you will fix the bug.
Posted by Daniel15, 01-11-2011, 10:01 PM
Are you sure about that? I can't see 5.3.5 in EasyApache, and the changelog says:
Posted by skywin, 01-11-2011, 10:03 PM
Yes, you can see it in cpanel forums. http://forums.cpanel.net/f145/case-4...ed-183882.html
Posted by GameFrame, 01-13-2011, 01:13 PM
Just tested it on both 32bit and 64bit servers using PHP 5.2.16 (cli) (built: Dec 23 2010 22:01:20): Testing float behaviour. If this script hangs or terminates with an error message due to maximum execution time limit being reached, you should update your PHP installation asap! For more information refer to . Your system seems to be safe.
Posted by Daniel15, 01-15-2011, 03:22 AM
I just checked EasyApache build 5291 and it only has PHP 5.3.4: http://ss.dan.cx/2011/01/daniel%40sp...5-18.22.02.png

Add to Favourites Print this Article