Hi

We've have stumbled across a performance issue using Doctrine and APCu. I have no idea if the problem actually is with Doctrine, APCu, or something else, but I'm opening this ticket because maybe it will ring a bell to you.

I've also opened a ticket on the Doctrine side, it contains a lot more information: http://www.doctrine-project.org/jira/browse/DDC-2832

The thing is we tried using Memcached and everything worked perfectly (no performance issue).

Doctrine ticket:

We have New Relic, so we have a bit of profiling, and here is what it shows:

... skipping to interesting bit
88s Doctrine\ORM\PersistentCollection::matching
  88s Doctrine\ORM\Persisters\BasicEntityPersister::loadCriteria
    43ms Orga_Cell - SELECT (MySQL query)
    88s Doctrine\ORM\Internal\Hydration\AbstractHydrator::hydrateAll
      88s Doctrine\...\SimpleObjectHydrator::hydrateAllData
        50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        47ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        59ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        52ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        51ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        45ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
        58ms Doctrine\...\SimpleObjectHydrator::hydrateRowData

(the stack trace is the one provided by New Relic, maybe their tool shows an incomplete stack trace? However judging by the content of the method and the numbers of rows, it seems correct)

As you can see, the numbers don't add up at all! A dozen of sub-calls takin 50ms each doesn't add up to a 80 seconds method call.

Keep in mind that when I disable the MetadataCache, then 80s turns into ~300ms and everything works as expected. That's a lot of difference.

So this is very weird.

Few more information:

• the operation runs in a worker, not a HTTP request
• we see the same behavior in every other operation, not just this one
• the PHP process uses 100% CPU of one core
• the RAM is not full (~ 50% used)
• APCu is not full
• APCu is at last version

If I make Doctrine use Memcached, then everything works great.

Hey,

I have a weird problem with apcu_delete: It returns false for me all the time, although a apcu_fetch with the appropriate parameters fetches the content from the key I want to delete correctly.

Can someone have a look at it please?

Thanks.

When I try to create a package from current git, I get an error:

pecl package package.xml
pecl install -f apcu-4.0.2.tgz

...
In file included from /var/tmp/apcu/apc.c:34:
/var/tmp/apcu/apc.h:127:28: error: apc_serializer.h: No such file or directory
In file included from /var/tmp/apcu/apc.c:34:
...

I think, the problem is simply, that apc_serializer is not included in package.xml.

This commit somehow prevents php_apcu.dll to load under PHP 5.5.1 VC11 X64:
286f70d

I did not yet find out where exactly it goes wrong. The Windows event log is not very descriptive...

We seem to be getting hung apaches w/PHP 5.5.0 RC3 w/APCu.

0x00007f1a9572853d in pthread_rwlock_wrlock () from /lib/x86_64-linux-gnu/libpthread.so.0
(gdb) bt
#0 0x00007f1a9572853d in pthread_rwlock_wrlock () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f1a90debd49 in apc_lock_wlock (lock=) at /home/phpbuild/buildphp-5.5.0RC3/apcu/apc_lock.c:129
#2 0x00007f1a90df05b9 in apc_cache_insert (cache=0x7f1a970d2960, key=..., value=0x7f1a83591880, ctxt=0x7fff1c983920, t=1371246459, exclusive=0 '\000') at /home/phpbuild/buildphp-5.5.0RC3/apcu/apc_cache.c:837
#3 0x00007f1a90df0b85 in apc_cache_store (cache=0x7f1a970d2960, strkey=0x7f1a9778ccc0 "AutoLoad::prefix::6::xxxxxxxxxxxxxxxxxxx::xxxxxxxxxxxxxxxxxx", keylen=52, val=0x7f1a977b5238, ttl=600, exclusive=0 '\000')

at /home/phpbuild/buildphp-5.5.0RC3/apcu/apc_cache.c:443

#4 0x00007f1a90dedb5b in apc_store_helper (ht=, return_value=0x7f1a977b5208, exclusive=0 '\000', return_value_ptr=, this_ptr=, return_value_used=)

at /home/phpbuild/buildphp-5.5.0RC3/apcu/php_apc.c:568

#5 0x00007f1a93f80de6 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f1a96df65b8) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_vm_execute.h:543
#6 0x00007f1a93f450d8 in execute_ex (execute_data=0x7f1a96df65b8) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_vm_execute.h:356
#7 0x00007f1a93ec8b70 in zend_call_function (fci=0x7fff1c983cb0, fci_cache=) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_execute_API.c:939
#8 0x00007f1a93eee3d7 in zend_call_method (object_pp=0x0, obj_ce=, fn_proxy=0x7f1a977137e0, function_name=0x7f1a977136a8 "autoload::loadone", function_name_len=,

retval_ptr_ptr=0x7fff1c983de0, param_count=1, arg1=0x7f1a97772900, arg2=0x0) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_interfaces.c:97

#9 0x00007f1a93dd8507 in zif_spl_autoload_call (ht=, return_value=, return_value_ptr=, this_ptr=, return_value_used=)

at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/ext/spl/php_spl.c:436

#10 0x00007f1a93ec8b14 in zend_call_function (fci=0x7fff1c983fc0, fci_cache=0x7fff1c984010) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_execute_API.c:957
#11 0x00007f1a93ec93fb in zend_lookup_class_ex (name=0x7f1a96f7d988 "xxxxxxxxx", name_length=9, key=0x7f1a977b52b0, use_autoload=1, ce=0x7fff1c9840d8)

at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_execute_API.c:1107

#12 0x00007f1a93ec9b22 in zend_fetch_class_by_name (class_name=0x7f1a96f7d988 "xxxxxxxxx", class_name_len=, key=, fetch_type=4)

at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_execute_API.c:1587

#13 0x00007f1a93f12c1a in ZEND_FETCH_CLASS_SPEC_CONST_HANDLER (execute_data=0x7f1a96df4ed8) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_vm_execute.h:1188
#14 0x00007f1a93f450d8 in execute_ex (execute_data=0x7f1a96df4ed8) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_vm_execute.h:356
#15 0x00007f1a93ed83b3 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend.c:1316
#16 0x00007f1a93e7661c in php_execute_script (primary_file=0x7fff1c9865b0) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/main/main.c:2481
#17 0x00007f1a93f8408d in php_handler (r=0x7f1a960f70a0) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/sapi/apache2handler/sapi_apache2.c:667
#18 0x00007f1a96239508 in ap_run_handler ()
#19 0x00007f1a9623997e in ap_invoke_handler ()
#20 0x00007f1a96249570 in ap_process_request ()
#21 0x00007f1a96246398 in ?? ()
#22 0x00007f1a9623ffa8 in ap_run_process_connection ()
#23 0x00007f1a9624e1d0 in ?? ()
#24 0x00007f1a9624e93a in ?? ()
#25 0x00007f1a9624f4e7 in ap_mpm_run ()
#26 0x00007f1a962244a4 in main ()

Reported here #52 and #58

Fixed in #45 but pulled to master branch, while new releases are from the simplify branch.

So 4.0.3 does not contain the fix.

• apc_bin.c needs a prototype for apc_copy_zval, else compiling gives
  "assignment makes pointer from integer without a cast"
• I don't think __USE_UNIX98 should be defined. Currently complation
  gives the warning:
  "apc_lock_api.h:32:0: warning: "__USE_UNIX98" redefined [enabled by default]
• there are casting (or use) issues between apc_malloc_t and apc_sma_malloc_f
• there are some zend_ulong vs size_t cast issues giving compilation
  warnings in apc_sma.c

I'm actually not sure if this is an issue for the apcu project or somewhere else.

I got the the error:

APCIterator::__construct() expects at most 4 parameters, 5 given

When passing, as usual with the old APC user cache, the 5 params defined here: http://php.net/manual/en/apciterator.construct.php

I just updated to version 4.0.1 and it seems like all functions are renamed to apcu__() instead of apc__(). I thought this should be a drop in replacement? Am I doing something wrong?

Let me know if I can provide more info but upgrading to PHP 5.5 with APCU has caused some issues with APCIterator. I upgraded to 4.0.2 and realize it's still in beta, but since doing so have seen considerable memory issues that were never a problem with APC. Notably listing keys with APCIterator:

    function list_keys($root,$key)
    {
        $keys = array();
        $cache = new APCIterator('user', '/^'.$root.','.$key.'/', APC_ITER_VALUE);
        foreach ( $cache as $key => $value ):
            array_push($keys,$key);
        endforeach;
        sort($keys);
        return $keys;
    }

Returns:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 7812535048 bytes) 

Any reason why it would be trying to allocate such a massive amount of memory just to list a few dozen keys?

/usr/libexec/gcc/x86_64-redhat-linux-gnu/4.8.1/ld: ext/apcu/.libs/apc_lock.o: undefined reference to symbol 'pthread_rwlock_wrlock@@GLIBC_2.2.5'

/usr/libexec/gcc/x86_64-redhat-linux-gnu/4.8.1/ld: note: 'pthread_rwlock_wrlock@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line

Notes: The 'glibc' library in Fedora 20 is Version 2.18.11

1. Using '--disable-apcu-rwlocks' does not resolve this.
2. Using '--disable-apcu-spinlocks' does not resolve this.
3. Using '--disable-apcu ' does resolve this.

The original APC serialization support was a bit different than APCu one.

The apc_register_serializer function was part of the apc_serializer.h header.

Which means this header need to be present at build time, but that apc.so could be missing at runtime.

With current implementation, as this function is in apcu.so, a extension, as igbinary which want to implement its serializer must requires apcu which is probably not a good idea.

With igbinary build against apc:

 $ php -n -d extension=igbinary.so -m
 ...
 igbinary

With igbinary build against apcu:

 $ php -n -d extension=modules/igbinary.so -m
 PHP Warning:  PHP Startup: Unable to load dynamic library 'modules/igbinary.so' - modules/igbinary.so: undefined symbol: apc_register_serializer in Unknown on line 0
 ...

I propose to revert to the original APC behavior

IIS version: 7.5.7600.16385
APC version: 4.0.3 5.5 Non Thread Safe (NTS) x86 http://pecl.php.net/package/APCu/4.0.3/windows
PHP version: 5.5.9

Error:

Faulting application name: php-cgi.exe, version: 5.5.9.0, time stamp: 0x52f2a88e
Faulting module name: php_apcu.dll, version: 5.5.4.0, time stamp: 0x52eb73db
Exception code: 0xc0000005
Fault offset: 0x000030fa
Faulting process id: 0x1aa0
Faulting application start time: 0x01cf32225008c0f4
Faulting application path: C:\PHP\php-cgi.exe
Faulting module path: C:\PHP\ext\php_apcu.dll
Report Id: 8e489ac4-9e15-11e3-8480-8c89a5711264

INI

[APCu]
extension=php_apcu.dll
apc.enabled=1

(no additional settings to APCu were set)

Opcache settings (might be related ??)

[opcache]
zend_extension = C:\PHP\ext\php_opcache.dll
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=16000
opcache.enable_file_override=1
opcache.error_log = C:\inetpub\php_logs\php_opcache_prod.log
opcache.log_verbosity_level=2

Here an example of zf2 code
https://github.com/zendframework/zf2/blob/master/library/Zend/Cache/Storage/Adapter/Apc.php#L331

$format   = APC_ITER_ALL ^ APC_ITER_VALUE ^ APC_ITER_TYPE ^ APC_ITER_REFCOUNT;
$regexp   = '/^' . preg_quote($internalKey, '/') . '$/';
$it       = new ApcIterator('user', $regexp, $format, 100, APC_LIST_ACTIVE);
$metadata = $it->current();

With apc extension metadata variable has this array

array (
  'key' => '777297316:843726ae1898521dafdfde945d71b59d',
  'num_hits' => 17,
  'mtime' => 1384856788,
  'creation_time' => 1384856788,
  'deletion_time' => 0,
  'access_time' => 1384857278,
  'mem_size' => 9816,
  'ttl' => 0,
)

Array keys differ with apcu.

array (
  'key' => '777297316:843726ae1898521dafdfde945d71b59d',
  'nhits' => 4,
  'mtime' => 1384856539,
  'ctime' => 1384856539,
  'dtime' => 0,
  'atime' => 1384857619,
  'mem_size' => 9816,
  'ttl' => 0,
)

Testcase:

• Insert one value into the cache with apc_store.
• Load apc.php
• Clear the cache
  The resulting page contains these warnings:

Warning: Division by zero in /home/cj/public_html/apcu-simplify/apc.php on line 756
Warning: Division by zero in /home/cj/public_html/apcu-simplify/apc.php on line 757
Warning: Division by zero in /home/cj/public_html/apcu-simplify/apc.php on line 758
Warning: Division by zero in /home/cj/public_html/apcu-simplify/apc.php on line 759

apc.shm_size => 1000M
0byte memory usage APC

The following commit removed compatability with APC:
4762c0d#L0L303

Example of code that ran under APC and will not work with APCu.

$apcIterator = new APCIterator(
    'user',
    ('/^'.preg_quote($cachePrefix, '/').'/'),
    APC_ITER_KEY
);

Worryingly, it didn't raise a significant error and was only found after investigating strange behaviour in our application. At the very least this should cause some kind of error - but the behaviour I would like to see is it accepting the first parameter and asserting it to be "user".

http://www.php.net/manual/en/apciterator.construct.php

This is a similar issue to the one raised here:
#18 apc_clear_cache does not accept $cache_type parameter

PHP Warning: apc_clear_cache() expects exactly 0 parameters, 1 given

If the API is changing, shouldn't it emit PHP Deprecated instead?

--- /home/tatsh/dev/apcu/config.m4      2013-07-04 04:03:33.067676349 -0700
+++ config.m4   2013-07-09 22:59:08.014319936 -0700
@@ -5,17 +5,17 @@
 PHP_ARG_ENABLE(apcu, whether to enable APCu support,
 [  --enable-apcu           Enable APCu support])

-PHP_APC_BC=yes
 AC_MSG_CHECKING(if APCu should provide APC full compatibility support)
 AC_ARG_ENABLE(apc-bc,
-[  --enable-apc-bc        Enable APC full compatibility support],
-[ if test "x$enableval" = "xno"; then
-    PHP_APC_BC=no
-  else
-    PHP_APC_BC=yes
-  fi
+[  --disable-apc-bc        Disable APC full compatibility support],
+[
+  PHP_APC_BC=no
+  AC_MSG_RESULT(no)
+],
+[
+  PHP_APC_BC=yes
+  AC_MSG_RESULT(yes)
 ])
-AC_MSG_RESULT($PHP_APC_BC)

 AC_MSG_CHECKING(if APCu should be allowed to use rwlocks)
 AC_ARG_ENABLE(apcu-rwlocks,

With the current version of 4.0.1 in PECL, the assertion for testing whether or not PHP_APC_BC should be yes is incorrect (any value always makes it change to no). This is the difference between the version on site and the one here.

In every installed PHP applications I have, the function apc_cache_info is called with 'user' as mentionned in the doc of APC. Applications expect to find the cache_list key in the returned array. It seems that this array doesn't contains this key. However, calling apc_cache_info without parameter returns the expected array.

Is it deliberated? Shouldn't APCu be compatible with APC?

Hi,

We are experiencing a lock down on apache processes related to APCu (actually we had the very same problem with APC 3.0.1 with PHP 5.2.10). Our current versions are:

• apache 2.2.3 (running on RHEL 5.7)
• PHP 5.4.24
• APCu 4.0.3 (both PHP and APCu are installed with remi packages from http://rpms.famillecollet.com/enterprise/5/remi/).

We have a somehow loaded server whose apc panel shows as follow:

There you can see the configuration and number of requests it had till it locked. The time it takes to lock varies a lot. Sometimes it just takes 5 minutes and some others it resists 20, 30 minutes or even almost 2 hours, with the same load.

The behavior is such that once some critical condition we can't identify occurs, any new apache process gets hung in the futex_wait call (as seen witch strace), as if it was never to be released because the first parameter in the futex_wait call is the same for all of them. We can kill those processes, but it isn't till we restart the whole apache that the problem disappear because any new request is stuck the same way as long as it uses APC cache.

As an additional information, almost all the entries we cache with APC have a 0 ttl as we want them to stay there forever as they don't change. We are also using OpCache for the opcodes.

After reading about similar problems we got to some ideas like the one stated in http://notmysock.org/blog/php/user-cache-timebomb.html so we changed all apc_store calls for apc_add ones with no success.

We know this isn't too much information to track the bug. If there are any other tests you want us to do, just tell us.

Thank you very much for your help.

4.0.3
and this output

        [0] => Array
            (
                [key] => WCF_409f75bc6a_wbb_BoardModeratorPermission-fb64df1fae01656a495d95af9e4181e5f100104f
                [ttl] => 259200
                [nhits] => 0
                [mtime] => 1390835810
                [ctime] => 1390835810
                [dtime] => 0
                [atime] => 1390835810
                [ref_count] => 0
                [mem_size] => 584
            )

its not compatible with the old apc api

Two instances of the same object (i.e. $obj1 === $obj2) if stored and then fetched from cache should be the same instance again.

class A {}
$obj1 = new A();
$obj2 = $obj1;
var_dump($obj1 === $obj2); // true
apcu_store('obj1', $obj1);
apcu_store('obj2', $obj2);
var_dump(apcu_fetch('obj1') === apcu_fetch('obj2')); // false, but should be true

Semi-real use case:

class User {}
class Post {
    public $createdBy;
    public $editedBy;
}
$user = new User();
$post = new Post();
$post->createdBy = $user;
$post->editedBy = $user;
// persist $post to DB
// ...
// hydrate $post from DB and cache it
apcu_store('post', $post);
// ...
// fetch $post from cache
$post = apcu_fetch('post');
// now $post->createdBy and $post->editedBy are two different instances of class User, but they should be the same instance as the original

How to detect if APCu is enabled? I have a factory method which takes care of providing the best cache instance available. Weather I run it from Apache or CLI, I need to detect if ACPu is enabled. With the former APC I could check it with function_exists('apc_fetch') or class_exists('APCIterator') but now they return true even if apc.enabled and/or apc.enable_cli are set to false.

while comparing perfomance with eaccelerator got such results:

index.php:

<?php
const WAIT_STEP = 3;
const DURATION = 10;

apcu_store('test', 1);

$start_time = apcu_fetch('start');
if ($start_time <= microtime(true)) {
    apcu_delete('start');
    apcu_delete('end');
    $start_time = null;
}

if (!$start_time) {
    $start_time = microtime(true) + WAIT_STEP;
    $end_time = microtime(true) + WAIT_STEP + DURATION;
    apcu_store('start', $start_time);
    apcu_store('end', $end_time);
}

sleep(1);
$start_time = apcu_fetch('start');
$end_time = apcu_fetch('end');

usleep(($start_time - microtime(true)) * 1000000);

$count = 0;
while (microtime(true) < $end_time) {
    for ($i = 0; $i < 100; $i++) {
        //$x = apcu_delete('test');
        $x = apcu_store('test', 1);
        $x = apcu_fetch('test');
        $x = apcu_delete('test');
    }
    $count++;
}
echo $count. "\n";die;

bash command:

1. run for a while:

while true; do (echo "" > out; for i in {1..6}; do curl -s http://localhost/ & >> out; done) | awk '{s+=$1} END {print s}' >> input && tail -n 1 input && sleep 2; done

2. you will see descending trend

3256
1873
1562
1319
1130
1081
990
871
740
564
657
562
625
537
498
527
553
559
531
422
452
440
462
424
430
442
441
413
421
420
414
398
404
392
385
377
378
334
295
311
347
331
311
329
320
327
299
251
256
269
266
243
239
247
272
273
272

Hi. Recently I've switched to php 5.5 with apcu extension and started to get weird fatal errors. After some investigations I found out that some of my User Cache Entries became broken.
At start I see this cached var

Array
(
    [strategy] => nested
    [activate_locking] => 
    [locking_timeout] => 3
    [left] => lft
    [level] => lvl
    [right] => rgt
    [root] => root
    [parent] => parent
    [useObjectClass] => AsPages\Entity\Page
)

And after several hours it becomes to

Array
(
    [└ьTоerro] => nested
    [░8`о�9`о] => 
    [=E■i�╕:`ом:`] => 3
    [ф<`о] => lft
    [uYо(] => lvl
    [Remov] => rgt
    [�] => root
    [└╢N║�] => parent
    [,|\о╠{\о<ю] => AsPages\Entity\Page
)

There were no such problems with php 5.4 and apc extension
The similar problem is described here http://stackoverflow.com/questions/18309583/doctrine-extension-bug-with-apcu-orm-treelistener-does-not-support-tree-type

I am using latest version of php 5.5.3 and dev version of apcu.
I face the problem both in Debian 7 and Ubuntu 12

Fixing #11 removed the configure errors I got in Windows. But now compiling does not work. Error message:

ext\apcu\apc_sma.c(657) : warning C4113: 'zend_ulong (__cdecl *)()' differs in parameter lists from 'apc_sma_get_avail_mem_f'
ext\apcu\apc_sma.c(657) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'apc_sma_check_integrity_f'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0
VC\BIN\cl.exe"' : return code '0x2'
Stop.

I got the same error message while building PHP 5.3.23, PHP 5.4.13 and PHP 5.5.0 beta 1. It was a snapshot build:

snapshot: forcing apcu on
snapshot: forcing apcu-debug on
snapshot: forcing --disable-apc-bc shared

Am I missing something? Should I configure otherwise?

While preparing the migration from PHP 5.4 to PHP 5.5, I tried to switch from pecl-APC to pec-APCu.

Under high load, my httpd starts to dump core while using APCu which is not the case when using APC.

I'm using the 4.0.1 release of apcu.

My Test Script: http://pastebin.com/ZMgR0LGg

How to reproduce:

• save the pastbin script "test_apc.php"
• execute the script one time in your browser to get the cache filled
• execute the following command to create load

ab -H "Connection:close" -c 20 -n 500 http://www/test_apc.php

with pecl-APC no errors occur at all, with pecl-APCu, httpd processed will start to dump core.

[Tue Aug 13 14:46:15 2013] [notice] Apache/2.2.25 (FreeBSD) mod_scgi/1.12 PHP/5.4.17 mod_ssl/2.2.25 OpenSSL/0.9.8y DAV/2 configured -- resuming normal operations
[Tue Aug 13 14:46:36 2013] [notice] child pid 90307 exit signal Bus error (10)
[Tue Aug 13 14:46:37 2013] [notice] child pid 90438 exit signal Bus error (10)
[Tue Aug 13 14:46:37 2013] [notice] child pid 90311 exit signal Bus error (10)
[Tue Aug 13 14:46:37 2013] [notice] child pid 90310 exit signal Bus error (10)
[Tue Aug 13 14:46:37 2013] [notice] child pid 90309 exit signal Bus error (10)
[Tue Aug 13 14:46:37 2013] [notice] child pid 90308 exit signal Bus error (10)
[Tue Aug 13 14:46:38 2013] [notice] child pid 90440 exit signal Bus error (10)
[Tue Aug 13 14:46:38 2013] [notice] child pid 90439 exit signal Bus error (10)
[Tue Aug 13 14:46:38 2013] [notice] child pid 90441 exit signal Bus error (10)
[Tue Aug 13 14:46:39 2013] [notice] child pid 90448 exit signal Bus error (10)

Verified with APCu 4.0.1 on:

• FreeBSD 9.2 PRERELEASE in a Jail
• FreeBSD 9.1 STABLE in a VirtualBox VM

I was not able to reproduce this in a out-of-the-box Ubuntu 11 with Apache 2.2.22 and PHP 5.3.10 with Suhosin Patch (default Ubuntu packages). The answer time just went dramatically low and the whole ab ended with

apr_poll: The timeout specified has expired (70007)
Total of 70 requests completed

But this might be a problem of my Ubuntu setup - maybe some DDoS protection... who knows.

see the gist for further information:
https://gist.github.com/peterwang/7588979

Serialization Support => php, eval

igbinary not found ..

https://github.com/phadej/igbinary/blob/master/apc_serializer.h

upgrading to a current apcu build

git reflog
      1 2c1f11c HEAD@{0}: clone: from https://github.com/krakjoe/apcu.git

on linux/64 with

php -v
    PHP 5.5.9-dev (cli) (built: Jan 17 2014 21:28:20) 
    Copyright (c) 1997-2014 The PHP Group
    Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
        with Zend OPcache v7.0.3-dev, Copyright (c) 1999-2014, by Zend Technologies

after configure success

phpize
./configure \
 --prefix=/usr/local/apcu \
 --libdir=/usr/local/apcu/lib64 \
 --enable-apcu --enable-apc-bc --disable-apcu-debug \
 --enable-shared --disable-static \
 --with-php-config=/usr/local/php5/bin/php-config \
  --disable-apcu-mmap \
  --enable-apcu-rwlocks \
  --disable-apcu-spinlocks \
  --enable-apcu-clear-signal \
  --with-gnu-ld \
  --enable-libtool-lock

make fails

make -j1

...
/bin/sh /usr/local/src/apcu/libtool --mode=compile /usr/bin/gcc-4.8 -D_GNU_SOURCE -I. -I/usr/local/src/apcu -DPHP_ATOM_INC -I/usr/local/src/apcu/include -I/usr/local/src/apcu/main -I/usr/local/src/apcu -I/usr/local/php5/include/php -I/usr/local/php5/include/php/main -I/usr/local/php5/include/php/TSRM -I/usr/local/php5/include/php/Zend -I/usr/local/php5/include/php/ext -I/usr/local/php5/include/php/ext/date/lib  -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -march=native -mtune=native -DHAVE_CONFIG_H  -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -march=native -mtune=native   -c /usr/local/src/apcu/apc_cache.c -o apc_cache.lo 
 /usr/bin/gcc-4.8 -D_GNU_SOURCE -I. -I/usr/local/src/apcu -DPHP_ATOM_INC -I/usr/local/src/apcu/include -I/usr/local/src/apcu/main -I/usr/local/src/apcu -I/usr/local/php5/include/php -I/usr/local/php5/include/php/main -I/usr/local/php5/include/php/TSRM -I/usr/local/php5/include/php/Zend -I/usr/local/php5/include/php/ext -I/usr/local/php5/include/php/ext/date/lib -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -march=native -mtune=native -DHAVE_CONFIG_H -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -march=native -mtune=native -c /usr/local/src/apcu/apc_cache.c  -fPIC -DPIC -o .libs/apc_cache.o
In file included from /usr/local/php5/include/php/main/php.h:38:0,
                 from /usr/local/src/apcu/apc.h:68,
                 from /usr/local/src/apcu/apc_cache.h:34,
                 from /usr/local/src/apcu/apc_cache.c:33:
/usr/local/src/apcu/apc_cache.c: In function ‘apc_cache_stat’:
/usr/local/src/apcu/apc_cache.c:1625:50: error: ‘apc_cache_slot_t’ has no member named ‘mtime’
             add_assoc_long(stat, "mtime", (*slot)->mtime);
                                                  ^
/usr/local/php5/include/php/Zend/zend_API.h:385:92: note: in definition of macro ‘add_assoc_long’
 #define add_assoc_long(__arg, __key, __n) add_assoc_long_ex(__arg, __key, strlen(__key)+1, __n)
                                                                                            ^
make: *** [apc_cache.lo] Error 1

I've been looking into upgrading our systems from 5.3.19 to 5.5.5, and APC 3.1.15 seems to be trampling memory, so I'm giving APCu a shot as a drop-in replacement. Dropped it in and... found two missing functions that we rely on. :)

Short of compiling hidef and figuring out how to implement it, are there any plans for having APCu provide these two functions?

Using PHP 5.5.5 and APCu 4.0.2 on CentOS 6.

Thanks!

ARG_ENABLE('apc-bc', 'Wether APCu should provide APC full compatibility support', 'yes')

should be

ARG_ENABLE('apc-bc', 'Wether APCu should provide APC full compatibility support', 'yes');

The output of the apc_cache_info() function differs slightly from that of the original function. We are using the cache_list subarray to gather information about the cache behavior, which is currently broken.

APCu:

php > $t = apc_cache_info('user');
php > print_r($t);
Array
(
    [cache_list] => Array
        (
            [0] => Array
                (
                    [key] => abc
                    [ttl] => 0
                    [nhits] => 0
                    [mtime] => 1382608917
                    [ctime] => 1382608917
                    [dtime] => 0
                    [atime] => 1382608917
                    [ref_count] => 0
                    [mem_size] => 656
                )
        )
)

APC:

php > $t_apc = apc_cache_info('user');
php > print_r($t_apc);
Array
(
    [cache_list] => Array
        (
            [0] => Array
                (
                    [info] => abc
                    [ttl] => 0
                    [type] => user
                    [num_hits] => 0
                    [mtime] => 1382608983
                    [creation_time] => 1382608983
                    [deletion_time] => 0
                    [access_time] => 1382608983
                    [ref_count] => 0
                    [mem_size] => 656
                )
        )
)

Got a "apc_clear_cache() expects exactly 0 parameters, 1 given" warning.

Calling apc_clear_cache('user') should flushes the user cache. apcu does not accept a parameter, so it's not fully BC. See http://php.net/manual/en/function.apc-clear-cache.php

Expected behaviour: apc_clear_cache should accept a parameter.

Hi,

As a drop in replacement for apc, with fully compatible PHP api, this extension should probably be named "apc" and not "apcu" as a lot of library / framework will rely on this name (load test, version test, ...)

Ex : with ZF, see zendframework/zendframework#4101

When storing array some keys are scrambled to some random value same length as previous key.

$apc_data = array(
    'test'=>'123', 
    'data'=>'test123456');
$apc_key = 'abc';
apc_store($apc_key, $apc_data);

• in same request apc_fetch returns ok keys
• on next request(s) apc_fetch returns something like this

Array
(
    [@��b] => 123
    [`��b] => test123456
)

PHP 5.5.1
APCu 4.0.2
Apache 2.2.15
CentOS release 6.4 x86_64

Building APCu v4.0.1 and running the tests on Darwin 12 shows that most of the tests are failing. The bracktrace from running tests/apc_001.php:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00000001038531f5 in make_slot [inlined] () at /Users/kabel/Documents/Installers/apcu/apc_cache.c:109
109             p->key = key[0];
(gdb) bt
#0  0x00000001038531f5 in make_slot [inlined] () at /Users/kabel/Documents/Installers/apcu/apc_cache.c:109
#1  0x00000001038531f5 in apc_cache_insert (cache=0x103abe730, key={str = 0x103b09338 "9eb_DB_PDO_MYSQL_DDL_catalog_product_entity_1", len = 46, h = 7252266301910437370, mtime = 1369433004, owner = 0}, value=0x103b08330, ctxt=0x7fff5fbfe8f0, t=1369433004, exclusive=0 '\0') at apc_cache.c:888
#2  0x0000000103852d4b in apc_cache_store (cache=0x103abe730, strkey=<value temporarily unavailable, due to optimizations>, keylen=<value temporarily unavailable, due to optimizations>, val=0x102bed5a8, ttl=2400, exclusive=0 '\0') at apc_cache.c:443
#3  0x00000001038506ca in apc_store_helper () at php_apc.c:568
#4  0x000000010041dde2 in zend_do_fcall_common_helper_SPEC (execute_data=0x102bb8050) at zend_vm_execute.h:643
#5  0x00000001003d8f98 in execute (op_array=<value temporarily unavailable, due to optimizations>) at zend_vm_execute.h:410
#6  0x00000001003b57c3 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:1315
#7  0x000000010035e262 in php_execute_script (primary_file=0x7fff5fbff4b8) at main.c:2492
#8  0x000000010043d7d2 in do_cli (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at php_cli.c:988
#9  0x000000010043c67a in main (argc=3, argv=0x7fff5fbffb90) at php_cli.c:1364

The tests all passed on v4.0.0

Getting error that APC_ITER_TYPE constant is not defined

http://www.php.net/manual/ru/apc.constants.php

The PHP api will retain compatibility with APC, as will common configuration options, providing a drop in replacement.

Introduced in 47d68f9, apc_clear_cache and apc_cache_info now no-longer take parameters.

Ideally these functions should only accept the "user" parameter, and error if called in the way that would have operated on the file cache.

hi,

replace apc_ by apcu_

see :

// clear cache
if ($AUTHENTICATED && isset($MYREQUEST['CC']) && $MYREQUEST['CC']) {
apcu_clear_cache();
}

if ($AUTHENTICATED && !empty($MYREQUEST['DU'])) {
apcu_delete($MYREQUEST['DU']);
}

if(!function_exists('apcu_cache_info')) {
echo "No cache info available. APC does not appear to be running.";
exit;
}

$cache = apcu_cache_info();

$mem=apcu_sma_info();

Basic Description

We are getting segfaults with APCU 4.0.2 on PHP 5.5 on Apache HTTPD 2.2.3. They appear to relate to calls to apc_cache_find failing to find contents of memory at a location that has seemingly not been allocated.

Severity

This is a serious bug that makes the host unusable until after HTTPD is restarted

Reproducing Error

We are experiencing this error in production code but we do not have a test script at this time. The general scenario is that we start up HTTPD and the code runs fine on a host for several hours, with no segfaults. After a few hours, a request segfaults and after that point, all requests segfault until HTTPD is restarted. It appears to happen under times of relatively higher (but still absolutely low) levels of load - host averages are 0.2-1.0, CPU is 90+% idle, low number of requests overall.

Stacktrace/GDB output

http://pastebin.com/Gbcd4gKE

While storing an item, we get a "GC cache entry 'key' was on gc-list for 3746 seconds. warning." for an different key.

Why is this warning generated? Is this is special case? Corrupted cache state? Can it be converted to a apc_debug call?

We convert all PHP warnings/errors to exceptions with a custom error_handler(), so this seemingly innocent warning generates an exception.

Notice: Undefined variable: cache_mode in /home/cj/public_html/apcu-simplify/apc.php on line 732

Notice: Undefined index: locking_type in /home/cj/public_html/apcu-simplify/apc.php on line 779

Hi!
Try this:

error_reporting(E_ALL);
ini_set('display_errors' ,1);
$dumpFilePath = "/path/to/apc.dump";
apcu_store("test", array(
    "t1" => array(
        "t11" => 11,
        "t12" => 12,
        "t13" => 13
    ),
    "t2" => array(
        "t21" => 21,
        "t22" => 22,
        "t23" => 23
    ),
    "t3" => array(
        "t31" => 31,
        "t32" => 32,
        "t33" => 33
    )
), 1000000);
$res = apcu_bin_dumpfile(null, $dumpFilePath);
echo $res;
$res = apcu_bin_loadfile($dumpFilePath);
echo $res;

My server returns 502 Bad Gateway. Message in log file: "kernel: pid 26326 (php-fpm), uid 80: exited on signal 11"
I use nginx, php 5.5.5

Thanks!

I don't understand why APCu's GC is whining, does the PHP dev can fix it ? If not, why displaying the message ?

apc_cache.c:210 :

/* good ol' whining */
if (dead->value->ref_count > 0) {
    apc_warning(
        "GC cache entry '%s' was on gc-list for %d seconds" TSRMLS_CC,
        dead->key.str, gc_sec
    );
}

When calling apc_cache_info('user'), the array keys seems to differ from apc's ones.
With apcu I got:

[nslots] => 4099
    [ttl] => 0
    [nhits] => 24
    [nmisses] => 42
    [ninserts] => 52
    [nentries] => 28
    [nexpunges] => 0
    [stime] => 1379344890
    [mem_size] => 58000
    [file_upload_progress] => 1
    [memory_type] => IPC shared
    [cache_list] => Array
        (
            [0] => Array
                (
                    [key] => Myapp__cake_core_cake_deu
                    [ttl] => 86313600
                    [nhits] => 0
                    [mtime] => 1379378443
                    [ctime] => 1379378443
                    [dtime] => 0
                    [atime] => 1379378443
                    [ref_count] => 0
                    [mem_size] => 584
                )
...

As far as I know, APC uses num_entries instead of nentries and start_time instead of stime. Also in the cache list entries, APC uses info instead of key. I think there are also more of these keys, but I currently have no apc installation to check them out.

Is it possible to get apcu's apc_cache_info() full compatible with apc's one?

What happens depending on if you answer yes/no.

In the following example:

 <?php
 $key="testkey";
 $i=PHP_INT_MAX;
 apc_store($key, $i);
 var_dump($j=apc_fetch($key));
 var_dump($i);
 var_dump($i==$j);

 apc_inc($key, 1);
 $i++;
 var_dump($j=apc_fetch($key));
 var_dump($i);
 var_dump($i==$j);

We get:

 int(9223372036854775807)
 int(9223372036854775807)
 bool(true)
 int(-9223372036854775808)
 double(9.2233720368548E+18)
 bool(false)

Don't you think we should have consistent behavior between interger overflow in cache and in PHP var ?

P.S. I haven't test, but I think APC is also affected.

Latest .git of 'apcu' shows this report in phpinfo() @ php 5.5.4

apcu
APCu Support disabled
Version 4.0.2
APCu Debugging Disabled
MMAP Support Disabled
Serialization Support broken
Revision $Revision: 328290 $
Build Date Oct 16 2013 11:39:07

Directive Local Value Master Value
apc.coredump_unmap Off Off
apc.enable_cli Off Off
apc.enabled Off Off
apc.entries_hint 4096 4096
apc.gc_ttl 3600 3600
apc.preload_path no value no value
apc.rfc1867 Off Off
apc.rfc1867_freq 0 0
apc.rfc1867_name APC_UPLOAD_PROGRESS APC_UPLOAD_PROGRESS
apc.rfc1867_prefix upload_ upload_
apc.rfc1867_ttl 3600 3600
apc.serializer igbinary igbinary
apc.shm_segments 1 1
apc.shm_size 1024M 1024M
apc.slam_defense Off Off
apc.smart 0 0
apc.ttl 28800 28800
apc.use_request_time On On

apc.writable /tmp /tmp

The only part of the report that concerns me is this "Serialization Support broken"