php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #64985 APC mixing up files
Submitted: 2013-06-07 06:29 UTC Modified: 2016-11-18 21:09 UTC
From: jiawei dot davidli at gmail dot com Assigned:
Status: Wont fix Package: APC (PECL)
PHP Version: 5.4.16 OS: Windows 7 x64
Private report: No CVE-ID: None
 [2013-06-07 06:29 UTC] jiawei dot davidli at gmail dot com
Description:
------------
Nginx 1.5.0 fastcgi with PHP 5.1.15 nts
APC Version: 3.1.13

This seems like an exact copy of #57498, which was submitted 6 years ago and 
closed with no resolution.

------------------------------
There are three files, A.php, B.php, and C.php. After restarting PHP, A.php is 
the first to be requested, and is executed normally. 
Subsequently, requesting B.php executes A.php. APC increments the hit counter 
for A.php, and B.php is never run or added to the cache. However, PHP $_SERVER 
variables, such as _SERVER["SCRIPT_FILENAME"], correctly points to B.php.
Strangely, requesting C.php works normally, and requesting B.php immediately 
afterwards works as well. However, if I request A.php again, B.php is no longer 
accessible, displaying A.php, and the only way to get B.php to execute is to 
request it immediately after requesting C.php.

The contents of A.php, B.php, and C.php are different and does not seem to 
influence the outcome, with the only deciding factor being the order in which 
the scripts are requested. The first script to be run after restarting PHP or 
clearing the cache always runs perfectly.

In my particular case, APC was working fine for over a week before these issues 
suddenly started, with no modifications of any server configurations or code. 
However, the timestamps and hashes on the files may have changed, as they are 
held under a git repository. However, resetting the modification, creation, and 
last access timestamps to the current time does not seem to resolve the issue, 
even after a complete reboot of the system.

I am certain that the opcode cache plays a major role in the appearance of this 
behavior, as disabling caching by setting apc.cache_by_default=0 resolves the 
issue. I have already tinkered with different settings in php.ini, to no avail. 
Here are my current settings, and I have included values that I tried in ().

[APC]
extension=php_apc.dll
apc.enabled=1
apc.shm_segments=1
apc.shm_size=128M
apc.num_files_hint=7000
apc.user_entries_hint=4096
apc.ttl=7200
apc.user_ttl=7200
apc.gc_ttl=3600
apc.stat=1
apc.include_once_override=0
apc.enable_cli=1 (0)
apc.file_md5=1 (0)
apc.canonicalize=0 (1)
apc.stat_ctime=1 (0)
apc.file_update_protection=2
apc.max_file_size=2M
apc.use_request_time=1 (0)
apc.slam_defense=0 (1)
apc.write_lock=1
apc.report_autofilter=0
apc.lazy_classes=0
apc.lazy_functions=0



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-07-08 14:20 UTC] henriksson86 at gmail dot com
Does the issue appear only after you perform a git pull?

Does restarting fastcgi resolve the issue?
 [2013-07-08 14:26 UTC] gopalv@php.net
The issue is that stat() in Win32 is not going through the same code-paths as the unix stat().

IIRC stat_ctime does nothing for win32 - we need a win32 version of that to avoid this issue.

Read apc.c:257.

I don't have a win32 box around with build tools or a php install to debug this.
 [2016-11-18 21:09 UTC] kalle@php.net
-Status: Open +Status: Wont fix
 [2016-11-18 21:09 UTC] kalle@php.net
APC is no longer supported in favor of opcache that comes bundled with PHP, if you wish to use the user cache, then look at PECL/APCu.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 07 05:01:29 2024 UTC