php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52144 Error: Base lambda function for closure not found
Submitted: 2010-06-22 13:30 UTC Modified: 2012-11-09 03:30 UTC
Votes:67
Avg. Score:4.8 ± 0.5
Reproduced:60 of 62 (96.8%)
Same Version:16 (26.7%)
Same OS:51 (85.0%)
From: taco at procurios dot nl Assigned: laruence (profile)
Status: Closed Package: APC (PECL)
PHP Version: 5.3.2 OS: linux
Private report: No CVE-ID: None
 [2010-06-22 13:30 UTC] taco at procurios dot nl
Description:
------------
I've rewritten some create_function() calls to lambda functions. After updating our servers with the new code the following error started to occur on one of the servers:

"Base lambda function for closure not found"

We immediately replaced the new code with the old and tried to figure out what went wrong. Since we couldn't find the bug and on development machines nothing went wrong, we gave the new code another try: everything worked like expected, without errors.

I'd really like to know what could have triggered this error, especially because we didn't change the code that triggered it.


Patches

tracing_modified_functions_classes.patch (last revision 2012-11-08 14:32 UTC by laruence@php.net)
bug52144_new.patch (last revision 2012-11-07 10:58 UTC by laruence@php.net)
autofilter_missing_funcs.patch (last revision 2012-11-03 14:59 UTC by gopalv@php.net)
auto_filter_on_missing_lambdas.patch (last revision 2012-11-02 12:18 UTC by gopalv@php.net)
bug52144.patch (last revision 2012-11-02 04:32 UTC by laruence@php.net)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-06-22 15:09 UTC] johannes@php.net
-Status: Open +Status: Feedback
 [2010-06-22 15:09 UTC] johannes@php.net
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.
 [2010-06-22 15:26 UTC] taco at procurios dot nl
-Status: Feedback +Status: Open
 [2010-06-22 15:26 UTC] taco at procurios dot nl
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.
 [2010-06-26 19:28 UTC] felipe@php.net
-Package: *Programming Data Structures +Package: Scripting Engine problem
 [2010-11-05 08:14 UTC] janne dot hietamaki at gmail dot com
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.
 [2010-11-05 08:27 UTC] janne dot hietamaki at gmail dot com
Updated to APC 3.1.5 and the problem still persists.
 [2011-06-06 20:04 UTC] nicolas at netlog dot com
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?
 [2011-07-21 17:07 UTC] aequasi at gmail dot com
Has this problem been resolved yet? having the same issues when i implement APC 
with symfony2
 [2011-08-12 06:32 UTC] hchinchilla at habitissimo dot com
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.
 [2011-10-20 14:05 UTC] s dot chernomorets at gmail dot com
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"
 [2011-10-21 11:32 UTC] peters at yandex dot ru
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';
 [2012-02-16 12:39 UTC] thoer81 at gmail dot com
I just want to add that this error message can also be caused by NuSphere PhpExpress
 [2012-03-16 15:41 UTC] johannes@php.net
Seems to be an APC issue
 [2012-03-16 15:41 UTC] johannes@php.net
-Package: Scripting Engine problem +Package: APC
 [2012-04-12 04:06 UTC] savetheinternet at tinyboard dot org
I'm getting this too with PHP 5.4.0 and APC 3.1.9.
 [2012-04-12 06:50 UTC] pajoye@php.net
-Status: Open +Status: Feedback
 [2012-04-12 06:50 UTC] pajoye@php.net
Hi!

Can you try using 3.1.10 please?
 [2012-04-12 14:40 UTC] mike dot lohmann at icans-gmbh dot com
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.
 [2012-06-22 12:18 UTC] thomasfotherby+pear at gmail dot com
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)
 [2012-07-24 14:00 UTC] pmaury at u-paris10 dot fr
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 ?
 [2012-07-25 14:57 UTC] andi dot primusportal at gmail dot com
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.
 [2012-07-26 17:03 UTC] pocallaghan at de-facto dot com
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
 [2012-07-30 07:44 UTC] aharvey@php.net
-Status: Feedback +Status: Open
 [2012-07-30 07:44 UTC] aharvey@php.net
Apparently still happening, per the last few comments.
 [2012-07-31 16:03 UTC] fabien at symfony dot com
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.
 [2012-07-31 17:44 UTC] pajoye@php.net
Any chance to get a small reproduce case (without having to change the cache ini 
settings, which is not recommended)?
 [2012-07-31 17:45 UTC] pajoye@php.net
-Status: Open +Status: Feedback
 [2012-10-31 07:54 UTC] Sebastian dot Nickel at fashiondays dot com
Hi,
is there any news on fixing this bug? We are experiencing it sometimes after a restart of apache.
 [2012-10-31 09:29 UTC] laruence@php.net
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
 [2012-10-31 09:46 UTC] laruence@php.net
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
.................
 [2012-10-31 11:45 UTC] gopalv@php.net
Can you post an easy sample test-case?
 [2012-11-01 02:38 UTC] laruence@php.net
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");
}
?>
 [2012-11-01 02:40 UTC] laruence@php.net
oh, sorry,  this is not the segfault one. 

it is , access it twice will trigger:

Fatal error: Base lambda function for closure not found
 [2012-11-01 03:09 UTC] laruence@php.net
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
 [2012-11-01 03:10 UTC] laruence@php.net
The following patch has been added/updated:

Patch Name: bug52144.patch
Revision:   1351739406
URL:        https://bugs.php.net/patch-display.php?bug=52144&patch=bug52144.patch&revision=1351739406
 [2012-11-01 11:00 UTC] hchinchilla at habitissimo dot com
@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.
 [2012-11-02 04:32 UTC] laruence@php.net
The following patch has been added/updated:

Patch Name: bug52144.patch
Revision:   1351830772
URL:        https://bugs.php.net/patch-display.php?bug=52144&patch=bug52144.patch&revision=1351830772
 [2012-11-02 04:35 UTC] laruence@php.net
@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...
 [2012-11-02 10:12 UTC] gopalv@php.net
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.
 [2012-11-02 10:25 UTC] gopalv@php.net
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.
 [2012-11-02 12:18 UTC] gopalv@php.net
The following patch has been added/updated:

Patch Name: auto_filter_on_missing_lambdas.patch
Revision:   1351858688
URL:        https://bugs.php.net/patch-display.php?bug=52144&patch=auto_filter_on_missing_lambdas.patch&revision=1351858688
 [2012-11-02 12:19 UTC] gopalv@php.net
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.
 [2012-11-02 13:41 UTC] laruence@php.net
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
 [2012-11-03 14:59 UTC] gopalv@php.net
The following patch has been added/updated:

Patch Name: autofilter_missing_funcs.patch
Revision:   1351954758
URL:        https://bugs.php.net/patch-display.php?bug=52144&patch=autofilter_missing_funcs.patch&revision=1351954758
 [2012-11-03 16:05 UTC] laruence@php.net
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..
 [2012-11-07 07:03 UTC] laruence@php.net
The following patch has been added/updated:

Patch Name: bug52144_new.patch
Revision:   1352271838
URL:        https://bugs.php.net/patch-display.php?bug=52144&patch=bug52144_new.patch&revision=1352271838
 [2012-11-07 07:06 UTC] laruence@php.net
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
 [2012-11-07 10:58 UTC] laruence@php.net
The following patch has been added/updated:

Patch Name: bug52144_new.patch
Revision:   1352285887
URL:        https://bugs.php.net/patch-display.php?bug=52144&patch=bug52144_new.patch&revision=1352285887
 [2012-11-08 14:32 UTC] laruence@php.net
The following patch has been added/updated:

Patch Name: tracing_modified_functions_classes.patch
Revision:   1352385171
URL:        https://bugs.php.net/patch-display.php?bug=52144&patch=tracing_modified_functions_classes.patch&revision=1352385171
 [2012-11-09 03:29 UTC] laruence@php.net
Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=328290
Log: Give the ability of aware of modified functions/classes to APC

which should fix bug #52144, #59298
 [2012-11-09 03:30 UTC] laruence@php.net
-Status: Feedback +Status: Closed -Assigned To: +Assigned To: laruence
 [2012-11-09 03:30 UTC] laruence@php.net
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.


 [2015-01-29 16:22 UTC] greg at endpoint dot com
What version of PHP (if any) has this fix? I am not seeing this bug number mentioned in the PHP 5 changelog...
 [2015-04-09 07:57 UTC] igor dot timoshenkov at gmail dot com
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?
 [2015-04-09 15:17 UTC] greg at endpoint dot com
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 05 16:01:30 2024 UTC