php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #59414 Duplicate cached variables (with the same key)
Submitted: 2010-09-13 06:38 UTC Modified: 2013-02-18 00:35 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: crejob at gmail dot com Assigned:
Status: No Feedback Package: APC (PECL)
PHP Version: 5.3.2 OS: Debian 6
Private report: No CVE-ID: None
View Developer Edit
 [2010-09-13 06:38 UTC] crejob at gmail dot com 
Description:
------------
After upgrading to php 5.3.3 and apc 3.1.4 from php 5.3.2 and php 3.1.3p1 one very bad thing happened: I see lot of duplicate entries in "User Cache Entries", and they fill whole cache after some time (it depends on load and apc.shm_size), resulting warnings "Unable to allocate memory for pool" like in bug #16966 (which are fatal for my application with php error_handler that dies after any warning).

In apc.php report "User Cache Entries" filtered by "foo" keyword and sorted by "last accessed", descending:

foo	0	648	2010/09/13 14:11:26
foo	0	648	2010/09/13 14:10:07
foo	0	648	2010/09/13 14:10:06
foo	0	648	2010/09/13 14:10:05
foo	0	648	2010/09/13 14:10:04
foo	0	648	2010/09/13 14:10:03
foo	0	648	2010/09/13 14:10:02
...

"Last modified" and "created at" columns are the same as "last accessed"

PHP Info:
Linux 2.6.32-5-amd64 #1 SMP Tue Jun 1 04:34:03 UTC 2010 x86_64 
Apache/1.3.42
PHP 5.3.3

PHP API 	20090626
PHP Extension 	20090626
Zend Extension 	220090626
Zend Extension Build 	API220090626,NTS
PHP Extension Build 	API20090626,NTS
Debug Build 	no
Thread Safety 	disabled 

APC
Version 	3.1.4
MMAP Support 	Enabled
MMAP File Mask 	no value
Locking type 	pthread mutex Locks
Revision 	$Revision: 301663 $ 

php.ini

[apc]

extension = /usr/local/php5/lib/php/extensions/no-debug-non-zts-20090626/apc.so
apc.shm_size = 256M
apc.ttl = 7200
apc.user_entries_hint = 65536
apc.slam_defense = 0

slam_defense disabled because of bug #16814 (warnings "Potential cache slam averted for key ..."), and the code below, perhaps, corresponds to that bug more than to this one (but results in apc.php report with duplicate variables, described above, are reproductible this way).

Reproduce code:
---------------
test.php:
for ($i = 0; $i<100; $i++) {
    echo apc_store('foo', $i, 0);
    echo ' '.apc_fetch('foo').'<br>';
}


Expected result:
----------------
1 0
1 1
1 2
1 3
1 4
1 5
1 6
1 7
1 8
1 9
...

Actual result:
--------------
1
1 1
1
1 3
1
1 5
1
1 7
1
1 9
1
1 11
1
1 13
1
1 15
1
1 17
1
1 19
1
1 21
1
1 23
1
1 25
1
1 27
1
1 29
1 30
1 31
1 32
1 33
1 34
1 35
...

Time to time result differs - only once I saw expected result, more frequently there was something like:
1
1 1
1
1 3
1
1 5
1 6
1 7
...

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-09-13 09:17 UTC] crejob at gmail dot com 
Worth to mention the result of test.php execution in APC 3.1.3p1, PHP 5.3.3:
1 0
0
0
0
0
...

Issue with duplicate variables not repeating in this case.
 [2010-09-16 19:46 UTC] mlove at passcal dot nmt dot edu 
I'm seeing the same problem here, too, on two different Fedora 13 64-bit test servers with PHP 5.3.3. It's occurring with 3.1.4 from the fedora repository, as well as any copy which I compile myself. It doesn't seem to matter what combination of compiler options I pick or whether I'm using IPC or shared memory.

I'm having to keep my production server on 5.2.10 for now.
 [2010-09-21 17:01 UTC] jeffdafoe at gmail dot com 
Seeing same problem with key duplication after upgrading our development server to PHP 5.3.3 and APC 3.1.4 .  

Have 2 other servers of identical hardware and OS (Centos 4), PHP 5.2.13 and APC 3.1.3p1 and problem doesn't exist there.
 [2010-10-20 15:33 UTC] kris at carlton dot ca 
There seems to be another problem that seems to be hinted above - apc_store() is storing a 'false' value, usually after the user cache has been cleared.

Even more frustrating, it seems to be intermittent, but can be reproduced by doing:

apc_store('foo', 'bar', 3600);

then:
                              
apc_clear_cache('user');

and again:

apc_store('foo', 'bar', 3600);
 [2010-10-25 10:26 UTC] sdfsdr at mailinator dot com 
Running into this too, it seems like there are issues with key names being different during store / retrieve operations. The key names look identical but I suspect that this change:

Bug #17978: standardize user keys to include NULs in identifier_len. Z_STRLEN_P() doesn't, so add to it.

Is the real cause of these issues. It seems some functions are not taking this new possibility of embedded NUL into account when comparing key names?
 [2010-10-29 01:01 UTC] dev at ni dot com 
I have this issue also with APC 3.1.4 - PHP 5.3.3
 [2010-11-01 16:32 UTC] d dot snytkine at gmail dot com 
I found this bug report because I was looking to see if anyone has the answer to this problem. All I can do is to add "me too" to this thread. Using php 5.3.3 with APC 3.1.4
I have 2 different server setups: once Apache with mod_php and another one is Lighttpd with php-fpm based factcgi.
Both of these setups have duplicate entry issues. I am using APC only to cache php classes, not using it to cache anything by keys, I have memcache for that.

Example:
[3] => Array
                (
                    [filename] => /usr/local/apache/sites/apacheserver/htdocs/!inc.php
                    [device] => 2051
                    [inode] => 37686147
                    [type] => file
                    [num_hits] => 3
                    [mtime] => 1288646012
                    [creation_time] => 1288646047
                    [deletion_time] => 0
                    [access_time] => 1288646140
                    [ref_count] => 0
                    [mem_size] => 119112
                )

            [4] => Array
                (
                    [filename] => /usr/local/apache/sites/apacheserver/htdocs/!inc.php
                    [device] => 2051
                    [inode] => 37686145
                    [type] => file
                    [num_hits] => 1
                    [mtime] => 1288641935
                    [creation_time] => 1288642030
                    [deletion_time] => 0
                    [access_time] => 1288642032
                    [ref_count] => 0
                    [mem_size] => 114984
                )

            [5] => Array
                (
                    [filename] => /usr/local/apache/sites/apacheserver/htdocs/www/index.php
                    [device] => 2051
                    [inode] => 37686144
                    [type] => file
                    [num_hits] => 3
                    [mtime] => 1288643813
                    [creation_time] => 1288646047
                    [deletion_time] => 0
                    [access_time] => 1288646140
                    [ref_count] => 0
                    [mem_size] => 28840
                )

            [6] => Array
                (
                    [filename] => /usr/local/apache/sites/apacheserver/htdocs/www/index.php
                    [device] => 2051
                    [inode] => 37686143
                    [type] => file
                    [num_hits] => 0
                    [mtime] => 1288640054
                    [creation_time] => 1288640063
                    [deletion_time] => 0
                    [access_time] => 1288640063
                    [ref_count] => 0
                    [mem_size] => 28840
                )
 [2010-11-04 05:04 UTC] pierre dot php at gmail dot com 
Please try using 3.1.5
 [2010-11-10 12:59 UTC] gopalv82 at yahoo dot com 
@d.snytkine:

Please note that php files appearing in the cache multiple times is perfectly normal.

From what i can see all four instances of index.php have different inode numbers. There is no way to figure out what was the original inode number for a file that's already been changed, so it cannot be selectively deleted easily.

That is not a bug.

As for the rest, I can't reproduce it at all with 3.1.5.
 [2010-11-24 21:43 UTC] dev at ni dot com 
I upgraded to 3.1.5 and this problem is still persist and even 
I got more apache crashes. Fortunately it seems that the 
problem has been fixed in 3.1.6dev 
http://downloads.php.net/pierre/php_apc-3.1-svn20101116-5.3-
vc6-x86.zip

Thank you very much
 [2010-11-27 11:28 UTC] sinisaculic at gmail dot com 
Hy I have a APC (3.1.5-dev) version installed on a  PHP Version 5.3.2-1ubuntu4.2

And i have this same damn problem.... since i updated to this version i get it even more often.... earlier i used apc 3.1.4 and almost never had this issue but now i have the damn thing after 100 tries.... and after i try to store a  different variable then it works... but after i clear the cache  the first variable wont be stored 100%!!!!
 [2010-11-28 16:31 UTC] kieran at tomatonetwork dot co dot uk 
We are also experiencing this issue after upgrading to 
php5.3.3 with APC 3.1.4 on FreeBSD 7.2 and 8.1. We have 
several servers running this setup and this bug is affecting 
them all. Ca anyone confirm/deny if 3.1.5 fixes this as there 
are conflicting reports and its not available in the FreeBSD 
port tree yet
 [2013-02-18 00:35 UTC] pecl-dev at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Oct 12 20:01:27 2024 UTC