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?

Having same trouble while ago.
Using FreeBSD amd64 + php 5.3 and 5.2

Problem solved by rollback to 3.0.19

I have the same problem and the error message isn't displayed with php's error system.
(Can't deactivate it by using "@")

same here, rollback to 3.1.2 and all is good again

I second this.

PHP5.3 and APC 3.1.3p1 on a Debian Lenny.

Technically, it was a feature put in to prevent this from happening

http://t3.dotgnu.info/blog/php/user-cache-timebomb

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

http://news.php.net/php.pecl.cvs/12914

php -dapc.slam_defense=0 will turn this off. Please test SVN.

I've done a little test case which succeeds on 3.0.19 and 
fails on 3.1.3p1 (under PHP fastcgi and CLI):

  http://www.gnome.org/~jdub/2009/apc-store-test.txt

I wonder if it's related to the following bug?

  http://pecl.php.net/bugs/bug.php?id=9662

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.

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)

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 

<pre>
apc_store('test', 'one'): 1
apc_store('test', 'two'): 1
apc_store('diff', 'thr'): 1
</pre>

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 ;)

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.

Thanks!

Note that, as linux.conf.au 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 
3.0.19.)

Can't get rid of this warning via apc.slam_defense=off

<?php
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;
?>

Outputs 

<pre>
string(14) "slam_defense: "
bool(false)
string(12) "write_lock: "
string(0) ""
1
[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.
</pre>
I'm using APC 3.1.3p1 on PHP 5.3.2-1ubuntu4.1 on Ubuntu 
Lucid x86.
apc.ini contents:
<pre>
extension=apc.so

apc.enabled = On
apc.enable_cli = On
apc.slam_defense = Off
apc.write_lock = Off
</pre>

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.

i've

  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/test.com/sites/all/modules/cacherouter/engines/apc.php on line 201

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

for reference, in case it might be helpful,

.../modules/cacherouter/engines/apc.php ->  http://pastebin.com/BCrFZ4bA

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?

Ben

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'                                   
false

apc.slam_defense = Off
apc.write_lock = Off


PS: 
 i tried to do:
        if(!$put) {             /* APC BUG WORKAROUND !! */
            apc_delete($key);
            $put=apc_store($key,$val,$timeout);
            if(!$put) {
                Log::warning( ... );
            }
        }

but it still does not work

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)
 #ifdef MULTIPART_EVENT_FORMDATA
 STD_PHP_INI_BOOLEAN("apc.rfc1867", "0", PHP_INI_SYSTEM, OnUpdateBool, rfc1867, zend_apc_globals, apc_globals)

Sorry for that.. better look here: http://debianforum.de/forum/pastebin.php?mode=view&s=34729

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.

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.

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....

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.

I find this bug a real hassle, too.

I'll be happy to see it fixed.

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.

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...

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: http://pecl.php.net/bugs/bug.php?id=16966

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:

httpd-2.2.15-5.el6.x86_64
php-5.3.2-6.el6.x86_64
php-pecl-apc-3.1.3p1-1.2.el6.1.x86_64

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).

APC version 3.1.6 affected too (php 5.3.5).

Hey there, is there a fix or patch for this yet?

I'm getting this error a lot on http://hairwegoproducts.com

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

How do we FIX it? And does turning off slam defense do harm?

There seems to be a lot of confusion and version-specific 
(mis)information 
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 
ini_set)

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 
0.

^
apc.write_lock has been around since APC v3.0.11 
(http://www.php.net/manual/en/apc.configuration.php).

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??

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?

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.

still waiting for a fix, zzzzzzz