php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60845 PHP 5.4 crash on 2nd request / APC caused
Submitted: 2012-01-23 05:16 UTC Modified: 2012-04-20 10:33 UTC
Votes:9
Avg. Score:5.0 ± 0.0
Reproduced:9 of 9 (100.0%)
Same Version:8 (88.9%)
Same OS:5 (55.6%)
From: sean@php.net Assigned: ab (profile)
Status: Closed Package: APC (PECL)
PHP Version: 5.4.0RC7 OS: Linux 2.6.38/Ubuntu
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: sean@php.net
New email:
PHP Version: OS:

 

 [2012-01-23 05:16 UTC] sean@php.net
Description:
------------
In testing my app against PHP 5.4.0RC6, I found that it would crash on the *second* request, within my front-end framework (which happens to be an old version of Lithium).

I've tried to identify exactly what userspace code is causing this, and I've managed to distill it down to around 20 PHP files, but I can't get this to happen in a *small* use case. Nor will it happen from the command line.

If I remove the APC extension, Apache does not crash. I've tested with APC 3.1.9 and also with APC from svn-trunk. Both crash.

Here is the code I've boiled down: http://files.seancoates.com/apccrash-li3.tar.bz2 ; point your DocumentRoot at frontend/webroot/

I've run it through gdb and valgrind (thanks much to Rasmus for hand-holding).

gdb: http://paste.roguecoders.com/p/a8769024952f7b616886ab5b06da358f.txt
valgrind: http://paste.roguecoders.com/p/3cfd5c63ff22fd9c556e5ebc240a7044.txt

I realize that "over-complicated" front-end code is part of the problem here, but even so, this app works on PHP 5.3, so something that changed is causing Apache (PHP with APC) to crash on 5.4.

Note also that even after Lithium has caused PHP to crash, other non-Lithium code continues to work (such as apc.php, included).

My gut tells me this is autoloader-related (Libraries.php), but I've been unable to narrow the actual test specifically to that.

If there's anything else I can provide, I would be happy to do so. Please ask. If, for some reason others can't reproduce this problem with the code I've posted above, I could probably package up a VirtualBox VM that exhibits this problem.



Test script:
---------------
Plese see http://files.seancoates.com/apccrash-li3.tar.bz2

Expected result:
----------------
No crash

Actual result:
--------------
Crash on 2nd request

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-01-23 18:09 UTC] uw@php.net
Are you using a ZTS build?
 [2012-01-23 20:31 UTC] sean@php.net
No ZTS. Here's the config.nice: http://paste.roguecoders.com/p/a4db5f454f16ee2af30457bc46c18698.txt

It's apache 2 on mpm-prefork, too.

S
 [2012-02-02 12:04 UTC] michal dot pipa dot xsolve at gmail dot com
I have similar problem. Default Symfony2 example page sends one XMLHttpRequest. 
So it makes two requests. First one is OK, page is rendered. But second request 
(XMLHttpRequest) crashes only with APC enabled. When I disable APC everything is 
OK.

My environment is PHP 5.4 (latest SVN revision), built-in web server and APC. 
I've tried both 3.1.9 and trunk APC versions.
 [2012-02-03 19:03 UTC] sean@php.net
Note: if you get a dispatch exception in the code above, you should be accessing /meta/phpinfo (I neglected to mention this).

New info:

- it's not spl_autoload_register (I tried replacing it with an __autoload implementation, and it still crashed)
- I can also "fix" the problem if I `touch(__FILE__);` in the autoloading function (or otherwise convince APC that it doesn't have a cached/corrupt copy)
 [2012-02-03 19:41 UTC] sean@php.net
More:
- if I manually load the classes with require (instead of the autoloader, it still crashes)
- I've trimmed down Libraries.php

Here's a new tarball: http://files.seancoates.com/apccrash-li3-2012020300.tar.bz2
 [2012-02-03 20:24 UTC] sean@php.net
-PHP Version: 5.4.0RC6 +PHP Version: 5.4.0RC7
 [2012-02-03 20:24 UTC] sean@php.net
This also happens on 5.4.0RC7 (updated bug to reflect this), and does not happen on PHP 5.3.10.
 [2012-02-05 22:29 UTC] nate dot abele at gmail dot com
Found it (I think).

The Libraries class (lithium/core/Libraries.php) contains a method called 
_params(). The first line of the method reads `$name = $name ?: "*";`, which 
ensures that empty values of `$name` are replaced with the default parameter 
value of the name parameter (method signature: `protected static function 
_params($type, $name = "*")`.

If I (a) comment this line out (the conditional has no effect on the test code), 
or (b) rewrite it to a long-hand if block, i.e.:


	if (!$name) {
		$name = '*';
	}

...the segfaulting goes away. If I uncomment it or replace it with the original, 
the segfaulting resumes, usually after 2 or 3 refreshes (I was testing in 
Chrome, so it probably does some stupidly-aggressive caching).
 [2012-02-05 23:09 UTC] nate dot abele at gmail dot com
I've put together a small test that seems to be enough to consistently reproduce the crash:

<?php

function bar($type, $name = "Bob") {
	$name = $name ?: "Bob";
	echo $name;
}
bar("Foo!");

?>

To mitigate the browser caching issues, I started testing with wget, and noticed that after the APC cache was primed 
(which of course caused PHP to segfault and return no data), wget would retry 3 times immediately, then wait 5 seconds 
and retry again.

This is where it gets weirder. The first 4 requests would segfault and return no data. The final request (after the 5-
second delay) wouldn't segfault, but always returned the same corrupt data. This pattern was repeatable consistently 
over the 10 or so iterations I tried.
 [2012-02-06 03:49 UTC] sean@php.net
Well done, Nate.

I can confirm that switching the ?: to the longhand form keeps my large test case from crashing, and additionally, I can confirm that the above small test case crashes on 5.4.0RC7 for me.

Here is a slightly smaller test case.
 
<?php
// DOES CRASH:
function bar() {
        $name = true;
        $name = $name ?: "Bob";
        echo $name;
}
bar();
 
?>

<?php
// DOES NOT CRASH:
function bar() {
        $name = null;
        $name = $name ?: "Bob";
        echo $name;
}
bar();
 
?>

Also, without the function context/wrapper, the crashy code above does not crash.

S
 [2012-02-06 04:18 UTC] sean@php.net
The small test case I posted above does not crash on PHP 5.3.10, FWIW.
 [2012-02-06 09:35 UTC] tyrael@php.net
we have seen multiple crashes related to the engine optimization made by Dmitry at  
http://svn.php.net/viewvc?view=revision&revision=298207

for example:
https://bugs.php.net/bug.php?id=55578
https://bugs.php.net/bug.php?id=60169

I would guess that this is also the case here.
 [2012-02-23 08:41 UTC] sixd@php.net
Also see https://bugs.php.net/bug.php?id=61164
 [2012-02-23 12:02 UTC] michal dot pipa dot xsolve at gmail dot com
I can confirm that removing ?: operator form Symfony2 code prevents crashes while 
APC is loaded.
 [2012-03-02 22:13 UTC] tomp at tomp dot co dot uk
I too am seeing this problem when using PHP 5.4.0 with the latest APC extension. On refresh of a page the server returns zero length response.
 [2012-03-08 09:33 UTC] ab@php.net
Please retest this with the current PHP+APC trunk, there was a fix according to 
https://bugs.php.net/bug.php?id=61238 .
 [2012-03-08 21:05 UTC] michal dot pipa dot xsolve at gmail dot com
Current PHP 5.4 + APC trunk does not crash on elvis operator now.

But it segfaults on PHP process exit (only with APC enabled): https://gist.github.com/9db2cceadd8ad09c29ff

Should I open another bug report for this?
 [2012-03-09 16:19 UTC] ab@php.net
No, this is now a known issue and it's being worked on it. Please see 
https://bugs.php.net/bug.php?id=61238 . But you could post your current gdb 
backtrace to be sure.
 [2012-03-12 14:39 UTC] ab@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: ab
 [2012-03-12 14:39 UTC] ab@php.net
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

see #61219
 [2012-04-20 09:18 UTC] rene dot welbers at unicepta dot de
i got the same error with the latest svn checkout.

Segmentation Faults when APC is enabled, doesn't matter which checkout. Tried 5.4.1RC1, 5.4.1RC1-dev, 5.5.0-dev and so on.
 [2012-04-20 10:33 UTC] ab@php.net
please open a new ticket because this one is already getting hairy and post a reproduce case there
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Wed Apr 08 05:01:24 2020 UTC