Multiple instances of the same software causes PHP "cannot redeclare class" errors when xcache enabled

[specky_rum]

PHP 5.4.3
Apache 2.2.22 64bit.
Win 2008 64bit
xcache 2.0.1

We have several instance of the Drupal CMS installed on our server which means several copies of the same files and file structure, just in different base directories. We do this so we can break a development version and not affect live, however, they run through one Apache instance and therefore one PHP and xcache instance.

It appears that when xcache is enabled we get frequent but intermittent and apparently fairly random "cannot redeclare class" errors in the PHP error log. These are fatal errors so the page completely fails when this happens. Disabling xcache completely eliminates the problem.

Since these errors are usually caused by either loading the same file twice (include instead of include_once) or by loading two files which have the same class declared in them I wonder if xcache is not using the entire filepath to identify cached files? After all, we have several instances of the same file, each of which has the same size etc.

Evidence for this comes from the error stack which shows the source of the error itself from instance A where all the other entries in the stack are in instance B. This should never happen and as stated, when xcache is disabled, it doesn't.

[moo]

IIRC, this is fixed in 3.0.0. can you please try 3.0.0 (or 3.0.1-dev)

[specky_rum]

Thanks very much for your quick response. I think the only reason we're not already using 3.0.1 is because I couldn't find a 64bit version and there isn't one at that link. Does that matter? If so, do you happen to know where I might get a 64bit Windows compile of it? Cheers.

[specky_rum]

Note that we're using 64 bit Apache and it regularly exceeds 2GB of memory usage!

[moo]

where did you get 64 bit version of PHP prebuilt for windows?

[specky_rum]

Here: ​http://www.anindya.com/php-5-4-3-and-php-5-3-13-x64-64-bit-for-windows/

All very unofficial but we had concerns over memory usage and crashes and these versions have helped resolve that. From this page the additional extensions (link at bottom) include xcache but only up to version 2.0.1, which is the version we were using.

[moo]

updated XCache build. you may want to get 5.4.8 (or 5.4.9) because PHP older than 5.4.7 (5.4.x) may not compatible with XCache that is build with newer PHP

[specky_rum]

updated to:
Apache 2.2.23 64bit
PHP 5.4.8 ts 64bit
xcache 3.0.1dev ts 64bit

The same problem occurs. When I disable xcache it stops the problem occurring.

If there's anything I can do to help diagnose this problem please let me know. Is there an ini setting that helps perhaps?

[moo]

need a short reproduce-able script/steps

[dschnepper]

We also ran into this problem when we upgraded from XCache 1.3.x to 2.0.1.

The root of the problem is the assumption that files-with-identical-source will results in identical opcodes. For PHP source files that contain the compile-time constants DIR or FILE, this assumption is not true.

I don't fully understand the use-case that lead to de-duplicating cached Opcode sets based on identical source files. While I understand the intent was to save on cache space - the use case that lead to this xcache feature doesn't apply on our site.

In our case, we have "revision X" and "revision X+1" active on the site at the same time, and phase an increasing percentage of traffic from one release to the next over a short time interval (1 hour). Many files are identical between the two releases, but files that make use of DIR or FILE are functionally different as release X and X+1 are stored in different directory trees.

[dschnepper]

Replying to moo:

IIRC, this is fixed in 3.0.0. can you please try 3.0.0 (or 3.0.1-dev)

We duplicated that the problem also exists in 3.0.0, 3.0.1, and 3.1.0-dev. (as well as 2.0.1)

[dschnepper]

Patch for 2.0.1

[dschnepper]

Patch for 3.0.1

[rluecke]

I've been working with dschnepper on this issue. In order to easily reproduce the error, I've built two virtual machine images: one is a fresh Ubuntu installation, and the other is that same fresh VM but with Apache 2, PHP 5.4, and XCache 2.0.1, which allows you to easily to reproduce the PHP errors via an ApacheBench? test. Please see this link for the steps involved, and the VM images:

​https://cloud.box.com/s/xwg69j5kxw5ywjdp461q

[moo]

The patch attached may remove the problem but also remove the feature of md5 dedup.

Simply disable md5 dedup would be a easier to avoid this bug before we can fix this unstable feature.

[specky_rum]

Following my initial report on this I spent some time creating a test case for you using a few very simple classes that called each other from different files. I copied them to different folders and then ran it from the different folders alternately and could never get it to fail!

Since then I have installed xcache on a multi Drupal install and seen it working and the only major difference I can see is that the one that works is 32 bit and the one that didn't was 64 bit. This may well be a red herring but I thought it worth mentioning just in case.

If you would like the test case I created that I couldn't actually get to fail let me know and I'll post it up, it just didn't seem much use since it needs to fail to prove anything!

Thanks for continuing to look into this. In our case we are now running separate Apache instances on our live server and using xcache on each so it is not an urgent issue but if I can help further I will.

[moo]

Thanks for the info. I'm making time to the test case env mention on the google group.

[moo]

Thanks to the test case, it can now be reported under my dev env. To reproduce:

• xcache.readonnly_protection=off (not reproduced: xcache.readonnly_protection=on and xcache.mmap_path=/tmp/xcache (not /dev/zero))
• concurrent request to the server

[moo]

fixed in [1238] for trunk (3.1.x). please confirm it and make a harder test before it is back port to 3.0.x

[moo]

confirmed fixed by dschnepper

backport as [1239] for branch 3.0.x