Opened 7 months ago

Last modified 2 weeks ago

#337 accepted defect

Files cached incorrectly between vhosts

Reported by: davidh87 Owned by: moo
Priority: major Milestone: undecided
Component: cacher Version: 3.1.0
Keywords: Cc:
Application: PHP Version: PHP/5.5.3-1ubuntu2.1
Other Exts: SAPI: Irrelevant
Probability: Blocked By:
Blocking:

Description

Hi,

I have multiple branches of the same project running on separate vhosts, with URLs such as trunk.localhost/, test1.localhost/. Due to the branches being for the same projects, most of the files have the same names.

Starting from a cleared PHP cache, loading one project works fine and relevant files are cached. Loading the second project then fails - the initially accessed index.php file is loaded and cached correctly, but any require'd PHP files are the cached versions of the other vhost's files.

Disabling the PHP cache yields the correct results for both vhosts.

Have also tried and confirmed that browser cache is not the issue.

Attachments (1)

xcache-debugging.zip (30.4 KB) - added by davidh87 7 months ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 7 months ago by moo

XCache have solve this problem by design. If it really happen like you said, it's a bug we should trace down. Please help to reproduce it, by providing you ini fil, making a short reproducable file if possible

The problem should relative to __FILE__ and __DIR__

comment:2 Changed 7 months ago by davidh87

Attachment added. examples/ contains 2 projects - xcache1 and xcache2. Also included apache configs in case (I locally edit /etc/hosts for named vhosts)

Loading xcache1.localhost/ gives the expected output ("index.html XCACHE1"). Loading xcache2.localhost then gives the same output. xcache2.localhost/phpinfo.php shows it is looking in the correct directory.

Interestingly, if line 2 of index.php is changed to echo "index.php - xcache2<br />"; (and xcache1 in the appropriate project), the problem is not there.

comment:3 Changed 7 months ago by moo

the attached zip is empty. please re-attach correct file

Changed 7 months ago by davidh87

comment:4 Changed 7 months ago by moo

sorry for the delay, it's Chinese new year here

"if line 2 of index.php is changed to.." <- index.php needs to be the same to reproduce the bug as sounds like __DIR__ problem to me.

however with the files you provided, it's not reproduced under my env. Lightpd + php 5.5 + xcache 3.1.1-dev (or 4.0-dev) . I wish you can allow me ssh to your reproduced box to see what happen there

comment:5 Changed 7 months ago by moo

btw, my email is phpxcache@…

comment:6 Changed 6 months ago by moo

please help to reproduce this bug

comment:7 Changed 6 months ago by davidh87

Sorry - I produced this on my work machine and can't give access to that. I'll sort out access to a personal server - sorry its taking so long.

comment:8 Changed 2 weeks ago by davidh87

I've emailed with details for an environment this is reproducible in

comment:9 Changed 2 weeks ago by moo

bot "Zend OPcache" and "require_once" is required to reproduce the problem. removing either one will be gone. can you please disable Zend OPcache and see if it is reproduced

comment:10 Changed 2 weeks ago by moo

  • Status changed from new to accepted

OK, the problem nailed down to opcache.optimization_level and constant folding of __DIR__ . "string"

the content of the two file is same so XCache store just single copy of compiled opcode. XCache try its best to recognize __DIR__ __FILE__ before caching and restore it to actual path on usage. but constant folding ruin the recognize/restore trick

for example, if __DIR__ equals to /www/test1:

  • without constant optimization {{{DIR . "/test"}} is compiled into two opcode, with separate literal string, "/www/test1" and "/test" which is recognized by XCache as {{DIR}}
  • with constant optimization {{{DIR . "/test"}} is compiled into 1 opcode, with just signle literal string, "/www/test1/test" which is NOT recognized by XCache as {{DIR}}

please set opcache.optimization_level=0 to workaround the problem

Note: See TracTickets for help on using tickets.