On august 16th 2012, the PHP group has released PHP 5.3.16, that brings 20 minor bug fixes.
The corresponding packages are now available on Dotdeb for Debian 6.0 “Squeeze” on both amd64 and i386 architectures. As usual, please read the ChangeLog before upgrading and be sure to use to the latest packages before reporting any issue.
36 replies on “PHP 5.3.16”
When can we expect dotdeb version of PHP 5.4.6 to be released?
I have this problem whith fpm in log WARNING: [pool www] child 2875 said into stderr: “*** glibc detected *** php-fpm: pool www: double free or corruption (!prev): 0x0a598110 ***”
And dont work FPM
Please help !!!
@nelmaster_vc : be sure to use the /etc/init.d/php5-fpm script provided with the package, it has a temporary fix
@Jason : please be patient, it’s currently building. Are you suffering a critical bug with PHP 5.4.5 that explains such a hurry? 🙂
I have to downgrade again to 3.5.15 whit php5-fpm 3.5.14 because when update to 3.5.16 show this error log WARNING: [pool www] child 2875 said into stderr: “*** glibc detected *** php-fpm: pool www: double free or corruption (!prev): 0x0a598110 ***” and FPM dont work !!! 🙁
Sorry I mean 5.3 and put wrong the # , sorry !!! 😉
Are there any chances to suhosin for PHP 5.4.x?
Suhosin is incomplete on PHP 5.4 and its development has been kinda “stalled”. I don’t think I’ll include it in PHP 5.4 if nothing evolves
Ok, anyway, thanks for info!
I don’t know exactly why yet, but my site didn’t like the 5.3.16 upgrade. I received plenty of 500 server issues with php5-fpm clients dying (exited on signal 6 (SIGABRT)) always after around 20s. I downgraded to dotdeb’s 5.3.15 and the problem immediately disappeared.
Update gave me SEGFAULTS and other stuff with APC active. Disabled APC for now and everything is running smoothly. Any idea what could be causing this? I was using APC along with PHP since more then a year with the same config (of course always everything from Dotdeb).
Richard, it’s possible we’ve encountered the same issue. We’re using APC, too, and I didn’t try to disable it. I had to rush because it’s a busy live site, hence I downgraded the whole release. Disabling APC would have been easier. 😉
So I’m not alone with this. Well, my site can easily life without APC, the nginx reverse proxy and FastCGI cache are taking care of it. But entering the admin section is a bit slower then before. Hopefully we’re going to see a new fixed APC version soon. 🙂
I think something is wrong with the memcached part. I get:
PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php5/20090626/memcached.so’ – libmemcached.so.11: cannot open shared object file: No such file or directory in Unknown on line 0
and there doesn’t seem to be a libmemcached11 package. The library seems to be available in the libmemcached10 package which doesn’t get upgraded because the name is the same as the previous one…
Never mind the previous post… it was an error on my side….
I have a similar problem with php5-fpm. It starts and then locks during startup and hangs forever until I kill it manually. I also had to downgrade to 5.3.15 because I have no idea how to fix this.
Really seems to be a Problem with APC and FPM. I’ve got plenty of SIGSEGV and SIGABRT in the php5-fpm.log until I remove/disable APC.
Any news regarding the APC Bug? Seems to be quite common.
FYI, a thread has been started on the FPM mailing list : https://groups.google.com/d/topic/highload-php-en/-msW1TNBH0I/discussion
Everything went fine for me. I am not using fpm…
Thank you Guillaume.
Same problem, 4 segfaults in a row which just make PHP hang.
Disabled apc and i’ll see what it does.
PHP-CLI given back only plaintext.
@asdfg : what does that mean?
php5-apc for both PHP 5.3 and PHP 5.4 brings APC 3.1.12, the most recent version. I’ll take a further look at the PHP bugtracker about it. Don’t hesitate to provide a backtrace of your crashes (after having installed php5-dbg)
The link to generate a backtrace : https://bugs.php.net/bugs-generating-backtrace.php
It seems that the bug has already been reported : https://bugs.php.net/bug.php?id=62877
Let’s see if your backtraces match.
I’ll provide new packages as soon as there’s a definitive APC fix.
Guillaume Plessis, maybe you could provide older versions of your packages? I would be very thankful for at least 5.3.14, because this bug really hurts.
@php user : as said on http://localhost:8080/instructions/ , old packages are kept on http://archives.dotdeb.org/
To those having FPM and APC segaults, could you please run this command and tell me if it fixes your issue?
(I applied the fix from this bug report : https://bugs.php.net/bug.php?id=62877 )
I got caught by the fpm/apc bug. Not dotdeb’s fault but a little irresponsible of php.net to issue a release which clearly hadn’t been tested on what I’d have thought is a fairly common setup.
For those that install updates using apt or aptitude it’s worth noting that you can check what updates have been done by looking in /var/log/apt/history.log and (unless you clear the apt cache) you’ll usually find older versions of the packages in /var/cache/apt/archives which can be put back easily using dpkg -i
I’ll try to test the dotdeb fix on my backup server later.
Hi Guillaume. Thanks so much for all your work @ dotdeb – it’s much appreciated. I ran the reinstall command above and, unfortunately, errors are still there – a long line of:
child XXXXX exited on signal 6 (SIGABRT) after 31.022805 seconds from start
Disabling apc fixes it.
Having now tested it, I can confirm that the patched php5-apc doesn’t fix the problem, sorry.
Are these issues still ongoing. I’ve just reinstalled my server and when ever I try to use /etc/init.d/php5-fpm restart it keeps coming back as failed.
As there is so many problems with this version is it possible to roll back the version that’s on dotdeb to one that’s working. If not can someone explain how I’d do this myself?
@Matty : you’ll find the former packages on http://archives.dotdeb.org/ . Fetch them (curl, wget, whatever…) and install them (dpkg -i) manually to roll back
I have been experiencing the crashes with PHP-FPM and APC from this update.
What I found out (at least in my case) was that the apc.filters setting seems to be triggering this. Any use of this option seems to trigger it.
Commenting out the apc.filters line in my APC configuration has completely eliminated the error. Of course, some other tweaks to the configuration were needed because of this, but it is still much, much better than having to disable APC altogether.