Please put up the apc.php that came with your apc install into the docroot and hit it.

Possibly, joomla is using apc cache and both instances are hitting the cache with the same key. More like

if(!($data = apc_fetch('foo'))) { include("foo.php"); }

perhaps - please check for it. I'm pondering on a 
apc.vhost_mask feature to allow the same code to be run in
different vhosts without issues.

By golly, you're right.  It never even crossed my mind that Joomla might have code to take advantage of APC.  The only place that specifically uses APC is Joomla 1.5's built-in cache handler, and I've got it turned off.  However, it would appear there is still something going on, because the first site to be hit gets cached, while the second site uses the first site's cached info (no evidence of the second site in the cached files output from apc.php).

I have multiple installs of Joomla 1.0 on this site, and they are unaffected.  The same is true of the multiple installs of vBulletin.  Now that I've some idea of what's happening, I'll open an issue with the Joomla 1.5 team.

Sorry to have troubled you for this when it wasn't your problem.

well, try this to an apache pid 

sudo gdb

(gdb) attach <pid>

(gdb) break zif_apc_fetch
(gdb) commands
 p executor_globals.current_execute_data->prev_execute_data->function_state.function->op_array.function_name
c
end
(gdb) continue

gdb will break whenever you hit apc_fetch and let you 
figure out what key it is inserting of sorts. That long 
line after p is the way to figure out the previous function
in the call trace.

Hit that apache with enough hits until you get lucky
and hit the pid you are attached to. Perhaps there's
some joomla extension/library that uses this ?

I'll be trying it this weekend, and I'll post back with the results.

I've tried this, but either I'm doing something wrong or I'm colossally unlucky, or this function is never being called, because I never got the break-point, despite several tens of thousands of page requests (I set up an instance of wget to request the home page of the site and just let it loop).  Probably I'll have to modify the Joomla source with some tracing logic to see what is going on.

I finally figured out what was going on here.

See, under Gentoo, we've got a configuration manager called webapp-config, which is used to install web applications like Joomla and AWSTATS.

webapp-config works by taking files from a central repository and copying them to the specified server (apache VHOST) directory.  It will make physical copies of the files if necessary, but prefers to make hard links, ala the ln command.

If I understand things correctly, a hard-link'd file is nothing more than a file-system pointer to the inode, meaning that only one physical copy of the file exists, but it appears two places in the directory tree.  That would mean that from APC's perspective, both file system entries are the same (because they in fact ARE the same file), and thus APC would serve up the first cached copy of the file.

In short, this is neither a Joomla problem nor an APC problem, but a configuration error caused by not understanding what the tool in question was doing.

Some more information on this, if you want to pursue.  I'm not sure if you want to consider this a bug or not, but it is certainly a situation where APC behaves differently from plain PHP.

Save the following code in a web-accessible directory somewhere as e.g. /var/www/www.testserver.org/htdocs/cachetest.php:

<?php
    echo dirname(__FILE__);
?>

now, make a hardlink to this file from some other directory like so:

ln cachetest.php /var/www/www.othertestserver.org/htdocs

Hit the first file with a browser, and observe the output, which should be:

/var/www/www.testserver.org/htdocs

Now, hit the second file with the web browser, and observe the output, which WE EXPECT TO be:

/var/www/www.othertestserver.org/htdocs

In fact, however, the output will be identical to the output from the first file.

Disable APC, and the output will be what we expect.  With APC enabled, the output will be identical for both files, and will be determined by which file gets cached first.

This is known/expected behavior, as PHP handles these values at parse time rather than run-time, which means APC is caching the results of the first parse.  This is why you get the same (cached) behavior on multiple requests.  Unfortunately this isn't something we can currently easily fix, our best bet is probably to figure out ways to make users more aware of when this is occurring.

After some research, it appears eAccelerator can be configured to store the file based on an MD5 hash of the file path rather than the inode.  This seems to solve the problem rather elegantly.  Perhaps something similar could be done for APC?

We do that too - just set apc.stat=0; and it'll never touch the disk & will use the path as a key.

But on-disk changes while running an app will not be reflected in the cache, because the nostat mode was written to increase performance rather than fix this problem.

Perhaps we could offer a mixed mode of these two options (full path stat), however this would mean adding yet another mode to the confusion and we'd need to allow the old way for those wanting this functionality.  

It would be nice to consolidate these different modes but I'm not seeing an easy way to do that and make everyone happy.

The other option of course is to rewrite on the fly these opcodes, but I don't think that's reasonable.

(marking this as a feature request, maybe there's something clever we can come up with?)

Are there any developments on this request?

According to <https://bugs.php.net/69618>, APC support has been
discontinued in favor of OPcache, APCu, the session upload
progress API and WinCache. Therefore this issue won't get fixed.