Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

Please also ensure that you're having no Zend extension or opcode cache or similar loaded.

The code in which the problem occurred looks like:

<?php
$methods = array(
'pfd_hor_pap'	=> function (&$v)
  {
    if (!empty($v)) {
      $v /= 13.66;
    }
    return true;
  },
// ...some other lambda functions
);
// ...code that uses the array with lambda functions
?>

The error occurs at the definition of the first lambda function in the array. The problem is that the error isn't reproducable (at least not when I want it to be). That's why I'd like to know what the typical situation is in which this error could occur.

I'm seeing this error quite often on our production servers. 

The problem seems to have something to do with APC cache, and after updating the files or apc_clear_cache() some random anonymous function call breaks at somewhere on our code.

I can reproduce the error on our production server almost every time, but I have not yet been able to build a reproducible test case. It seems to be a concurrency issue, so the reproduction most probably 
requires concurrent APC cache clearing and lambda function calls.

We're running PHP 5.3.3 with APC 3.1.4 on RHEL. I could try to upgrade to APC 3.1.5 next.


Any help would be appreciated.

Updated to APC 3.1.5 and the problem still persists.

Hi there,

We're experiencing the same problem here at Netlog. Also on production servers 
when we have some load. Unable to isolate this issue yet. We're running php 5.3.5 
and apc 3.1.9. If we disable APC the problem goes away.

Any clues here?

Has this problem been resolved yet? having the same issues when i implement APC 
with symfony2

We are having the same problem here at Habitissimo. using debian with PHP 5.3.6 and APC 3.1.9. We had to replace APC with xcache to avoid this problem.

It seems option apc.write_lock=Off solves this problem partially.

We have config with closure in style "<?php return array( ...., function() {...}, ... ); 
?>"
and include (not include_once) it seceral time per request.

1. If apc_cache_write_lock(apc_cache TSRMLS_CC) (apc_main.c:602) was
unsuccessful at first include() then APC return old_compile_file. Function
old_compile_file store compiled closures into internal zend hash function_table but
not to cache. 

2. If apc_cache_write_lock(apc_cache TSRMLS_CC) was successful at second
include() then APC try to store opcode (apc_main.c:610-617), but function
apc_copy_new_functions(apc_compile.c:1333,1340-1343) not found new functions
(our closures) because zend hash function_table contains this closures already
(closures were compiled at first include()). So APC copy compiled array from 
included
file to cache without closures.

3. php-code try to call closure -> "Base lambda function for closure not found"

We have spend many hours trying to reproduce this bug in our production 
environment and analyzing apc source code. There is more then one way to get 
this error in production, but in many cases you need to use load testing 
software or something to reproduce the bug.
Here is the simple example that reproduces this bug. It is not the case in 
production systems but it is easy to reproduce and adresses absolutely the same 
problem. The root of the problem was explained here by s dot chernomorets at 
gmail dot com.

You should create 3 scripts and put them in a directory under document root.
Then make request to script1.php and click the link (or make request to 
script2.php)

======filename:lambda_function.php
<?
function() {}
?>
======filename:script1.php
<?php
apc_clear_cache();
ini_set('apc.cache_by_default', 0);
include('lambda_function.php');
ini_set('apc.cache_by_default', 1);
include('lambda_function.php');
?>
<a href="script2.php">CLICK TO REPRODUCE ERROR</a>
======filename:script2.php
<?php
include 'lambda_function.php';

I just want to add that this error message can also be caused by NuSphere PhpExpress

Seems to be an APC issue

I'm getting this too with PHP 5.4.0 and APC 3.1.9.

Hi!

Can you try using 3.1.10 please?

Hi.

We tried with PHP 5.3.3 and it is still the same behavior. Even with 3.1.10 or 
the current svn-trunk.

Just to weigh in and say we have just got bitten by the same bug. Suddenly 
started after an Apache restart. And another Apache restart fixed it.

> PHP Fatal error:  Base lambda function for closure not found in...

The line reported in the error was the one that starts with "function" in the 
below code:

<?php
...
$connections = array_filter(
    $connections,
    function(SocialConnection $connection) use ($data) {
        return $connection->connected_mem_id == $data->mem_id;
    });
...
?>

php --version
PHP 5.3.6-13ubuntu3.7 with Suhosin-Patch (cli) (built: May  4 2012 00:50:06) 

APC Version => 3.1.9 (from php -i | less)

Hi,

We meet the same error with the CMS Moodle. It is not easy to reproduce it because this bug occurs only sometimes. For me, it is when I use the administration search box. Here the server and software specs :

Moodle 2.3.1
Ubuntu 10.04 Server LTS with APC cache 3.1.3p1
PHP 5.3.2-1ubuntu4.17
Apache/2.2.14 (Ubuntu)

I got a blank page and in the apache log I got :

PHP Fatal error:  Base lambda function for closure not found in /var/www/moodle/mod/lti/settings.php on line 69

Here the line 69 :

69 $configuredtools = array_filter($types, function($value) {
70       return $value->state == LTI_TOOL_STATE_CONFIGURED;
71    });

I can still access the rest of Moodle fine, it's just the admin section that's broken during few minutes only.

More information and other Moodle's users experience about it : http://moodle.org/mod/forum/discuss.php?d=199275

How can I help ?

I also have a problem with this issue. I'm randomly getting this error. I also 
tried to disable/enable a lot of different apc settings. Still the same bug ( ? ) 
What am I doing wrong? My code is definitely not wrong because it works after 
restarting the server but occurs randomly when I change files again.

We too are having the same issue on a Ubuntu 12.04 system running...

PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) (built: Jun 13 2012 17:19:58) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

Apparently still happening, per the last few comments.

This bug is rather critical as Composer (http://getcomposer.org/), a dependency 
management tools that is getting a lot of traction in the PHP world, is using an 
anonymous function for its autoloader.

Any chance to get a small reproduce case (without having to change the cache ini 
settings, which is not recommended)?

Hi,
is there any news on fixing this bug? We are experiencing it sometimes after a restart of apache.

I can reproduce this, but can not find a simple way to fix it now due to the 
lambda specific declare mechanism.

will keep looking . 

thanks

Actually, this is not a lambda specific issue, 

following test scripts will result a segfault(the similar reason):

index.php:
----
<?php
apc_clear_cache();
ini_set('apc.cache_by_default', 0);
include('test.php');
ini_set('apc.cache_by_default', 1);
include('test.php');
?>
<a href="seg.php">click here to segfault</a>
----

test.php
----
<?php
if (!function_exists("test")) {
    function test() {}
}
?>
----

seg.php
----
<?php
include "test.php";
test();
----

access the index.php, then click the link. segfault:

(gdb) bt
#0  0x00000000008b93a0 in do_bind_function (op_array=0x2b5fbe661100, 
opline=0x2b5fc2a315d8, function_table=0x1f36d000, compile_time=0 '\0') at 
/home/huixinchen/opensource/trunk/Zend/zend_compile.c:4510
#1  0x000000000091ebf2 in ZEND_DECLARE_FUNCTION_SPEC_HANDLER 
(execute_data=0x2b5fbe629310) at 
/home/huixinchen/opensource/trunk/Zend/zend_vm_execute.h:1098
#2  0x000000000091af12 in execute_ex (execute_data=0x2b5fbe629310) at 
/home/huixinchen/opensource/trunk/Zend/zend_vm_execute.h:440
#3  0x000000000091af8e in execute (op_array=0x2b5fbe65be70) at 
/home/huixinchen/opensource/trunk/Zend/zend_vm_execute.h:464
#4  0x00000000008dd589 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /home/huixinchen/opensource/trunk/Zend/zend.c:1309
#5  0x000000000084fee8 in php_execute_script (primary_file=0x7fffd6cc3a40) at 
/home/huixinchen/opensource/trunk/main/main.c:2468
.................

Can you post an easy sample test-case?

Hey, I am not sure, if this is a *easy* test :) , access twice will trigger a 
segfault.

<?php
$is_second = apc_fetch("bug52144_accessed");

if (!$is_second) {
    $script = __DIR__ . "/script.inc";
    if (!file_exists($script)) {
        file_put_contents(__DIR__ . "/script.inc", '<?php return function() {} ?
>');
    }
    apc_clear_cache();
    ini_set("apc.cache_by_default", 0);
    include("script.inc");
    ini_set("apc.cache_by_default", 1);
    include("script.inc");
    apc_add("bug52144_accessed", true);
} else {
    apc_delete("bug52144_accessed");
    include("script.inc");
}
?>

oh, sorry,  this is not the segfault one. 

it is , access it twice will trigger:

Fatal error: Base lambda function for closure not found

since this is a low probability issue, we should not introduce a complicated fix 
for that, so a  simple fix is disable compiling cache if any error occurred in 
this request lifecycle.

a patch has been attached

@laruence@php.net:

¿Low probability? This error fires every time a lambda function is used in my app (which happens fairly often). Your fix would make no difference to me to use APC or not using it at all, as it would be disabled for almost every request.

@hchinchilla it's probability, it only occurred while you first attempt to cache a 
file failed, and that file must contains a dynmaic declaration. 

my fix is disable the cache if there is something wrong in the previous caching 
attempts.  

but it still works for other read only cache_compile...

The error triggers every time the lambda is loaded wrong, but this definitely has 
scope for a better fix.

Hidden cross-file dependencies needs a cache object purge of some sort anyway.

We do some fancy juggling with classes already, we need to figure out how to do 
the equivalent with dynamically declared closures.

To update the bug - the real issue is that the CG(function_table) is not updated 
when a closure is added.

We track CG(function_table) in preference to EG(function_table) which contains 
only the runtime aliases of functions (the regular DECLARE_FUNCTION) and such 
usually.

Updated with the new patch.

I probably need a day or two to find some time to QA it properly.

But essentially, whenever a lambda is found missing inside a file - we recompile 
it & cache the new one.

g0pz, actually, it's not a lambda specific issue, see my previous comments.

all dynamic declaration may cause that bug. some of them will trigger a 
segfault.

the key problem here is the "new function add" which apc calls the 
old_compile_file. 

if the previous cache compile fail, then the functions/classes added by 
old_compile_file can not be aware by apc if the second attempt successed

and if we check all dynamic delaration files, then it will be a little overhead.

so, I still think my patch is a proper one :)

thanks

hmm, I was trying to convert the reproduce test script into phpt. but is  that 
okey for testing it with php5.4 server?

in that case, we are testing the other "php" executeable , not current 
sapi/cli/php, hope I made myself clear..

I made another fix in another way, which is:

hook the CG(function_table)'s pDestructor, then we can got which function has 
been modified while in zend_compile_file.

please NOTE this patch is only a quick fix, aims to explain the idea. so only 
functions hook is implemented, the classes's one isn't impelmented, but it also 
be very easy ,  if we think this way is okey..

thoughts? 

thanks

The fix for this bug has been committed.

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.

What version of PHP (if any) has this fix? I am not seeing this bug number mentioned in the PHP 5 changelog...

Guys, the last comment makes sense: we are experiencing this issue on the following system:

PHP 5.3.10-1ubuntu3.17 with Suhosin-Patch (cli) (built: Mar 17 2015 12:00:21)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

So the question is - what version of php is this bug fixed in?

For the record, I am still seeing this using:

PHP 5.4.36-0+deb7u3

It occurs when using MediaWiki, even if direct APC usage by MediaWiki is disabled by changing $wgMainCacheType to CACHE_NONE or CACHE_DB. SMW (SemanticMediaWiki) has some lamda functions that trigger it. It is also annoyingly hard to reproduce/debug, as the error pops up, clears itself, and then pops up again at a random time later.