|  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
Avg. Score:5.0 ± 0.0
Reproduced:9 of 9 (100.0%)
Same Version:8 (88.9%)
Same OS:5 (55.6%)
From: 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
 [2012-01-23 05:16 UTC]
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: ; point your DocumentRoot at frontend/webroot/

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


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

Expected result:
No crash

Actual result:
Crash on 2nd request


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-01-23 18:09 UTC]
Are you using a ZTS build?
 [2012-01-23 20:31 UTC]
No ZTS. Here's the config.nice:

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

 [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 

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]
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]
- 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:
 [2012-02-03 20:24 UTC]
-PHP Version: 5.4.0RC6 +PHP Version: 5.4.0RC7
 [2012-02-03 20:24 UTC]
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:


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


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]
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.
function bar() {
        $name = true;
        $name = $name ?: "Bob";
        echo $name;

function bar() {
        $name = null;
        $name = $name ?: "Bob";
        echo $name;

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

 [2012-02-06 04:18 UTC]
The small test case I posted above does not crash on PHP 5.3.10, FWIW.
 [2012-02-06 09:35 UTC]
we have seen multiple crashes related to the engine optimization made by Dmitry at

for example:

I would guess that this is also the case here.
 [2012-02-23 08:41 UTC]
Also see
 [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]
Please retest this with the current PHP+APC trunk, there was a fix according to .
 [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):

Should I open another bug report for this?
 [2012-03-09 16:19 UTC]
No, this is now a known issue and it's being worked on it. Please see . But you could post your current gdb 
backtrace to be sure.
 [2012-03-12 14:39 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: ab
 [2012-03-12 14:39 UTC]
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

 For Windows:
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]
please open a new ticket because this one is already getting hairy and post a reproduce case there
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Jul 17 19:01:29 2024 UTC