php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #56528 Wrong cache file hits on include_path change
Submitted: 2005-09-06 13:26 UTC Modified: 2006-01-27 10:06 UTC
From: futrega at gmail dot com Assigned:
Status: Closed Package: APC (PECL)
PHP Version: 4.3.10 OS: Fedora Core 4
Private report: No CVE-ID: None
 [2005-09-06 13:26 UTC] futrega at gmail dot com
Description:
------------
APC uses wrong cache file if there are two files of the same name but accessed with different include_path settings. See reporoduce code for info.




Reproduce code:
---------------
./text.php:
<? $text = "1111111111111111"; ?>

./abc/text.php
<? $text = "2222222222222222"; ?>

./index1.php:
<? include("text.php"); echo $text; ?>

./index2.php:
<? ini_set("include_path", "abc:."); include("text.php"); echo $text; ?>


Expected result:
----------------
If you access index1.php, it will include text.php from the current directory (right) and APC will cache that text.php; the output will be "111111111111111".

If you access index2.php next, it should include text.php from the "abc" directory but will wrongly use the cached text.php from the current directory instead; the output will be again "111111111111" but should be "22222222222222".

It also works the other way around: if you access index2.php first, text.php from "abc" directory will be cached, and the output for index2.php will be 22222222222222 (right).

If you access index1.php after that, the output will also be "2222222222222222" (wrong) but should be "111111111111111".



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-01-22 17:17 UTC] shire at tekrat dot com
It looks to me like stat() is being called (for absolute paths?) before we check include paths, but this causes us to read in the wrong file with the same filename.  It also gives the current directory a higher priority than the include paths.  I've made the following changes, and it corrects my reproduction of this error.  (I had to turn off KeepAlive as well to reproduce consistently due to the sapi stat.)

This should cause the include paths to have a higher priority, unless the path is absolute.  If it's absolute we just use regular stat, and short circuit the apc_stat_paths call.

I believe this could also be related to bug #560: http://pecl.php.net/bugs/bug.php?id=5600

Please let me know if this is a possible fix, or if I'm just shooting in the dark.  -thx!

Index: apc.c
===================================================================
RCS file: /repository/pecl/apc/apc.c,v
retrieving revision 3.8
diff -u -r3.8 apc.c
--- apc.c18 Jul 2005 05:14:02 -00003.8
+++ apc.c22 Jan 2006 21:38:24 -0000
@@ -294,6 +294,13 @@
 
     assert(filename && buf);
 
+    // if path is absolute, go with it
+    if(IS_ABSOLUTE_PATH(filename, strlen(filename))) {
+        if(apc_stat(filename, buf) == 0) {
+            return 0;
+        }    
+    }
+    
     paths = apc_tokenize(path, DEFAULT_DIR_SEPARATOR);
     if (!paths)
         return -1;
Index: apc_cache.c
===================================================================
RCS file: /repository/pecl/apc/apc_cache.c,v
retrieving revision 3.101
diff -u -r3.101 apc_cache.c
--- apc_cache.c6 Jan 2006 07:58:27 -00003.101
+++ apc_cache.c22 Jan 2006 21:38:25 -0000
@@ -599,7 +599,8 @@
     if(tmp_buf) { 
 buf = *tmp_buf;
     } else {
-        if (apc_stat(filename, &buf) != 0 && apc_stat_paths(filename, include_path, &buf) != 0) {
+        //if (apc_stat(filename, &buf) != 0 && apc_stat_paths(filename, include_path, &buf) != 0) {
+        if (apc_stat_paths(filename, include_path, &buf) != 0) {
 #ifdef __DEBUG_APC__
             fprintf(stderr,"Stat failed %s - bailing (%s) (%d)\n",filename,SG(request_info).path_translated);
 #endif   if (apc_stat_paths(filename, in
 [2006-01-27 10:06 UTC] ilia at prohost dot org
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.


 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Thu Jan 27 12:03:34 2022 UTC