|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58832 New warning "Potential cache slam averted for key"
Submitted: 2009-08-26 23:54 UTC Modified: 2013-10-29 06:20 UTC
Avg. Score:4.0 ± 1.1
Reproduced:27 of 28 (96.4%)
Same Version:17 (63.0%)
Same OS:4 (14.8%)
From: dave at hobodave dot com Assigned: rasmus
Status: Closed Package: APC (PECL)
PHP Version: 5.3.3 OS: OS X
Private report: No CVE-ID:
 [2009-08-26 23:54 UTC] dave at hobodave dot com
After upgrading to APC 3.1.3p1 when running my unit tests I am 
spammed by over a thousand of the following message:

[Wed Aug 26 22:48:22 2009] [apc-warning] Potential cache slam 
averted for key 'foo' in /Users/hobodave/foo.php on line 3.

Also subsequent attempts to set the same key in the user cache 
will result in the second failing.

Reproduce code:
apc_store('foo', 1); 
apc_store('foo', 2); 

echo apc_fetch('foo');

Expected result:

Actual result:
[Wed Aug 26 22:48:22 2009] [apc-warning] Potential cache slam 
averted for key 'foo' in /Users/hobodave/foo.php on line 3.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-09-01 09:02 UTC] jason at xlntads dot com
I have to second this issue, getting tons of these now on the 3.1.3p1..... is there a way to disable the cache slam check explicitly through an ini var or something?
 [2009-09-07 18:51 UTC] need4spam at k dot ru
Having same trouble while ago.
Using FreeBSD amd64 + php 5.3 and 5.2

Problem solved by rollback to 3.0.19
 [2009-09-18 21:09 UTC] marc dot bennewitz at giata dot de
I have the same problem and the error message isn't displayed with php's error system.
(Can't deactivate it by using "@")
 [2009-09-20 20:14 UTC] max at mctekk dot com
same here, rollback to 3.1.2 and all is good again
 [2009-09-22 02:35 UTC] desfrenes at gmail dot com
I second this.

PHP5.3 and APC 3.1.3p1 on a Debian Lenny.
 [2009-09-22 06:28 UTC] gopalv82 at yahoo dot com
Technically, it was a feature put in to prevent this from happening

But since it'd be a good thing to turn off in QA or unit-tests, you can do that with the "new, but old" apc.slam_defense

php -dapc.slam_defense=0 will turn this off. Please test SVN.
 [2009-10-22 21:07 UTC] jdub at bethesignal dot org
I've done a little test case which succeeds on 3.0.19 and 
fails on 3.1.3p1 (under PHP fastcgi and CLI):

I wonder if it's related to the following bug?
 [2009-10-22 21:26 UTC] jdub at bethesignal dot org
I should note that I've tried turning off slam_defense (as 
noted in an earlier comment on this bug) in both the test 
script itself and in the ini file.
 [2009-10-23 06:03 UTC] jdub at bethesignal dot org
I have just tried SVN trunk as of today ("svn info" deets 
below)... same fail case as 3.1.3p1 -> calling apc_store with 
the same key twice fails.

Last Changed Author: pajoye
Last Changed Rev: 289714
Last Changed Date: 2009-10-18 02:33:20 +1100 (Sun, 18 Oct 
 [2009-10-23 08:09 UTC] gopalv82 at yahoo dot com
whoa, jdub? I'm in distinguished company here :)

I think I know what's up, so to speak.

ini_set() does not work for any of apc settings because they are set for PHP_INI_SYSTEM and cannot be overridden. 

I should change that for slam_defense.

But when I do dump apc.slam_defense = Off; in my apc.ini or when I set it with -d, it does work without errors (fresh svn build, cli mode).

$ /opt/php53/bin/php -dapc.slam_defense=off apc-store-test.txt 

apc_store('test', 'one'): 1
apc_store('test', 'two'): 1
apc_store('diff', 'thr'): 1

you can find me on irc in case you need more help.

So, if I work out a fix for this bug ... can you get me a discount for LCA this year? #bribesaccepted ;)
 [2009-10-23 22:06 UTC] jdub at bethesignal dot org
No idea what I buggered up earlier when I tested with 
apc.slam_defense=off in the ini file, but yes -- it does 
indeed work as expected once slam_defense is properly 
switched off.


Note that, as is organised by a different mob 
in a different city each year, I do not wield any influence 
for the Wellington event in 2010. ;-)

(As a matter of interest, based only on this microbenchmark, 
SVN trunk as of yesterday is perhaps 33% slower than 
 [2010-05-07 04:42 UTC] confik at gmail dot com
Can't get rid of this warning via apc.slam_defense=off

var_dump('slam_defense: ', ini_get('apc.slam_defense'));
var_dump('write_lock: ', ini_get('apc.write_lock'));

apc_store('foo', 1);
apc_store('foo', 2);

echo apc_fetch('foo') . PHP_EOL;


string(14) "slam_defense: "
string(12) "write_lock: "
string(0) ""
[Fri May  7 13:32:14 2010] [apc-warning] Potential cache 
slam averted for key 'foo' in 
/home/conf/limb_rep/limb/limb/test.php on line 6.
I'm using APC 3.1.3p1 on PHP 5.3.2-1ubuntu4.1 on Ubuntu 
Lucid x86.
apc.ini contents:

apc.enabled = On
apc.enable_cli = On
apc.slam_defense = Off
apc.write_lock = Off
 [2010-05-21 19:53 UTC] marcosbl at gmail dot com
Same thing here, APC 3.1.3p1 ,  Apache/2.2.9 (Debian), PHP 5.3.2-0

After setting a key value, you can't replace it.
 [2010-06-10 01:20 UTC] bendj095124367913213465 at gmail dot com

  apc 3.1.3p1, apache 2.2.15, php 5.3.2, on opensuse 11.2

i'm seeing

 [Wed Jun  9 21:59:23 2010] [apc-warning] Potential cache slam averted for key 'prod-cache_menu_lookup' in /srv/www/ on line 201

manifest on a Drupal install (fwiw ...).

for reference, in case it might be helpful,

.../modules/cacherouter/engines/apc.php ->

i spoke to an earlier commenter who suggested that patching out the warning was required, even after disabling apc.slam_Defense=off in apc.ini

Has this been addressed fixed in any of the recent svn work?

 [2010-06-16 11:10 UTC] parf at comfi dot com
Getting tons of this messages.
My application logic is broken because this bug,
Going to use memcached instead until this bug is resolved.

php 5.3.3
apc 3.1.3p1

>apc_store("x",1)                                           true                                                                                                             
> apc_store("x",1)
[Wed Jun 16 11:06:52 2010] [apc-warning] Potential cache slam averted for key 'x'                                   

apc.slam_defense = Off
apc.write_lock = Off

 i tried to do:
        if(!$put) {             /* APC BUG WORKAROUND !! */
            if(!$put) {
                Log::warning( ... );

but it still does not work
 [2010-06-25 07:49 UTC] se at plista dot com
FYI: apc.slam_defense isn't in the source code anymore. So setting it is like doing nothing.

We wanted it back (unit tests an other things) so maybe you want patch the source code with this:


--- a/APC-3.1.3p1/apc_cache.c
+++ b/APC-3.1.3p1/apc_cache.c
@@ -1144,6 +1144,10 @@
     unsigned int keylen = key->data.user.identifier_len+1;
     unsigned int h = string_nhash_8(key->data.user.identifier, keylen);
+    if(!APCG(slam_defense)) {
+        return 0;
+    }
     /* unlocked reads, but we're not shooting for 100% success with this */
     if(lastkey->h == h && keylen == lastkey->keylen) {
         if(lastkey->mtime == t) {
--- a/APC-3.1.3p1/apc_globals.h
+++ b/APC-3.1.3p1/apc_globals.h
@@ -86,6 +86,7 @@
     zend_bool canonicalize;      /* true if relative paths should be canonicalized in no-stat mode */
     zend_bool stat_ctime;        /* true if ctime in addition to mtime should be checked */
     zend_bool write_lock;        /* true for a global write lock */
+    zend_bool slam_defense;      /* true for ignoring possible slam defense */
     zend_bool report_autofilter; /* true for auto-filter warnings */
     zend_bool include_once;      /* Override the ZEND_INCLUDE_OR_EVAL opcode handler to avoid pointless fopen()s [still experimental] */
     apc_optimize_function_t apc_optimize_function;   /* optimizer function callback */
--- a/APC-3.1.3p1/php_apc.c
+++ b/APC-3.1.3p1/php_apc.c
@@ -91,6 +91,7 @@
     apc_globals->canonicalize = 1;
     apc_globals->stat_ctime = 0;
     apc_globals->write_lock = 1;
+    apc_globals->slam_defense = 0;
     apc_globals->report_autofilter = 0;
     apc_globals->include_once = 0;
     apc_globals->apc_optimize_function = NULL;
@@ -199,6 +200,7 @@
 STD_PHP_INI_BOOLEAN("apc.canonicalize", "1",    PHP_INI_SYSTEM, OnUpdateBool,           canonicalize,     zend_apc_globals, apc_globals)
 STD_PHP_INI_BOOLEAN("apc.stat_ctime", "0",      PHP_INI_SYSTEM, OnUpdateBool,           stat_ctime,       zend_apc_globals, apc_globals)
 STD_PHP_INI_BOOLEAN("apc.write_lock", "1",      PHP_INI_SYSTEM, OnUpdateBool,           write_lock,       zend_apc_globals, apc_globals)
+STD_PHP_INI_BOOLEAN("apc.slam_defense", "0",    PHP_INI_SYSTEM, OnUpdateBool,           slam_defense,     zend_apc_globals, apc_globals)
 STD_PHP_INI_BOOLEAN("apc.report_autofilter", "0", PHP_INI_SYSTEM, OnUpdateBool,         report_autofilter,zend_apc_globals, apc_globals)
 STD_PHP_INI_BOOLEAN("apc.rfc1867", "0", PHP_INI_SYSTEM, OnUpdateBool, rfc1867, zend_apc_globals, apc_globals)
 [2010-06-25 07:58 UTC] se at plista dot com
Sorry for that.. better look here:
 [2010-06-25 08:00 UTC] se at plista dot com
I forget: this paste is only available until 25 July 2010 so if you need it after that and don't want to copy it out of the post before ask me.
 [2010-11-10 16:03 UTC] dave at hobodave dot com
Why was this closed? This bug still exists and has not been 
addressed. My server is bombarded by thousands of cache slam 
warnings, and it is not even caching a single copy of the 
supposedly slammed key.
 [2010-11-25 11:08 UTC] sinisaculic at gmail dot com
I use PHP Version 5.3.2-1ubuntu4.2 

And i used 3.1.4 and all was ok but now updated my version to 3.1.5 -  dev version and i get slams ALMOST always and apc_store is almost unusable after you once stored and accessed the value... Can someone pls remove the damn thing completely....
 [2010-11-26 01:18 UTC] gopalv82 at yahoo dot com
For everyone bitching about, this was put in because of horrible write-slams on the cache, which was causing seg-faults on load.

I've fixed the multiple store() in the same script issue, 
which should fix the unit-tests case. 

Please test current svn before I tag it for a release.
 [2010-12-12 13:05 UTC] evan at prodromou dot name
I find this bug a real hassle, too.

I'll be happy to see it fixed.
 [2010-12-12 13:23 UTC] evan at status dot net
By the way, I've never had a write-slam on the cache. You're saving me from something I don't have a problem with.
 [2011-01-04 22:37 UTC] jason at green dot cx
Is there any news on this issue?

Is there an official place other than here I should be 
looking? Google tells me nothing... 

Many thanks for the efforts of the devs of apc. It's nice to 
have.... working...
 [2011-01-22 20:29 UTC] ilia dot cheishvili at gmail dot com
This issue, aside from filling up logs, is a headache when developing.  If, as a good developer, you have error reporting displaying everything, then this error will usually create output that is sent before the headers are, which pretty much "breaks" the response as a chain of errors proceed to occur.  Therefore, I developed a patch for APC 3.1.7 that I am forced to run with.  The patch makes it so that the errors are still written to PHP's standard error log, but don't clobber the HTTP response output.  Perhaps this will be useful to someone:

diff -u -r APC-3.1.7/apc_cache.c APC-3.1.7-patched/apc_cache.c
--- APC-3.1.7/apc_cache.c       2011-01-11 12:06:38.000000000 -0700
+++ APC-3.1.7-patched/apc_cache.c       2011-01-21 18:49:40.000000000 -0700
@@ -1270,6 +1270,7 @@
 /* {{{ apc_cache_is_last_key */
 zend_bool apc_cache_is_last_key(apc_cache_t* cache, apc_cache_key_t* key, unsigned int h, time_t t TSRMLS_DC)
+    char *log_message;
     apc_keyid_t *lastkey = &cache->header->lastkey;
     unsigned int keylen = key->data.user.identifier_len;
 #ifdef ZTS
@@ -1288,7 +1289,10 @@
         if(lastkey->mtime == t && FROM_DIFFERENT_THREAD(lastkey)) {
             /* potential cache slam */
             if(APCG(slam_defense)) {
-                apc_warning("Potential cache slam averted for key '%s'" TSRMLS_CC, key->data.user.identifier);
+                log_message = emalloc((key->data.user.identifier_len + 40) * sizeof(char));
+                sprintf(log_message, "Potential cache slam averted for key '%s'", key->data.user.identifier);
+                php_log_err(log_message TSRMLS_CC);
+                efree(log_message);
                 return 1;

By the way, I have provided another patch that addresses a similar issue here:
 [2011-01-26 11:20 UTC] williama_lovaton at coomeva dot com dot co
Is there any fix for this bug?

I'm seeing this all the time in my logs:
[apc-warning] Potential cache slam averted for key '477d3a5342475fec464ac20b93b407abVardefManager.Users.User' in /usr/share/sugarv6/include/utils/external_cache/SugarCache_APC.php on line 84

In this case it's about a new version of Sugar we are trying to configure in the company I work for.

I'm using the new Red Hat Enterprise Linux 6.0 with the following packages:


I'm willing to compile a new RPM for APC if there are some degree of certainty that the bug is being worked on.

I guess the workaround for now will be to disable caching in Sugar (which I'm not really sure if it's possible).
 [2011-02-19 21:36 UTC] normandiggs at gmail dot com
APC version 3.1.6 affected too (php 5.3.5).
 [2011-03-07 11:28 UTC] mikemckoy at gmail dot com
Hey there, is there a fix or patch for this yet?

I'm getting this error a lot on

I have two servers hosting websites using APC and this is 
horribly annoying. I suspect a lot of people are experincing 

How do we FIX it? And does turning off slam defense do harm?
 [2011-04-20 21:30 UTC] jbyers at gmail dot com
There seems to be a lot of confusion and version-specific 
about this bug.

As of APC 3.1.7 and PHP 5.3.6, do the following:

 - set apc.slam_defense = 0 and apc.write_lock = 1 in 
php.ini (not via 

You will no longer get slam_defense warnings in your logs 
and the write_lock 
avoids the race condition that necessitated slam_defense in 
the first place.

It seems that now that apc.slam_defense is deprecated, the 
default should be 
 [2011-06-24 10:13 UTC] ryan dot pendergast at gmail dot com
apc.write_lock has been around since APC v3.0.11 

Can't you just set apc.write_lock = 1 and apc.slam_defense = 
0 without having to upgrade to APC 3.1.7 and PHP 5.3.6??
 [2012-05-31 15:41 UTC] nektir at gmail dot com
ryan - have you successfully set apc.write_lock = 1 and apc.slam_defense = 
0 without having to upgrade to APC 3.1.7 and PHP 5.3.6? does it get rid of the messages and do no harm?
 [2012-08-09 12:01 UTC] sergiu dot ionescu at gmail dot com
For anyone still having this issue, i can confirm that upgrading apc to a newer version - in my case 3.1.9 - will resolve the issue without the need for further configuration.
You won't need to upgrade php, PHP 5.1.0 or newer should be enough.
 [2013-10-29 06:20 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: rasmus
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Sun Apr 20 19:01:51 2014 UTC