Opened 2 years ago

Closed 20 months ago

Last modified 14 months ago

#296 closed defect (fixed)

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

Reported by: specky_rum Owned by: dschnepper
Priority: major Milestone: 3.0.2
Component: cacher Version: 3.0.0
Keywords: Cc: dschnepper@…
Application: PHP Version: 5.4.x
Other Exts: SAPI: Irrelevant
Probability: Blocked By:
Blocking:

Description

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.

Attachments (2)

ticket-296-2.0.1.patch (2.7 KB) - added by dschnepper 20 months ago.
Patch for 2.0.1
0001-ticket-296-3.0.1.patch (2.8 KB) - added by dschnepper 20 months ago.
Patch for 3.0.1

Download all attachments as: .zip

Change History (30)

comment:1 follow-up: Changed 2 years ago by moo

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

comment:2 Changed 2 years ago by 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.

comment:3 Changed 2 years ago by specky_rum

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

comment:4 Changed 2 years ago by moo

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

comment:5 Changed 2 years ago by 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.

comment:6 Changed 2 years ago by 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

comment:7 Changed 2 years ago by specky_rum

  • PHP Version changed from 5.4.3 to 5.4.8
  • Version changed from 2.0.1 to 3.0.0

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?

comment:8 Changed 2 years ago by moo

need a short reproduce-able script/steps

comment:9 Changed 20 months ago by dschnepper

  • Owner changed from moo to dschnepper

comment:10 Changed 20 months ago by dschnepper

  • Status changed from new to assigned

comment:11 Changed 20 months ago by 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.

comment:12 in reply to: ↑ 1 Changed 20 months ago by 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)

comment:13 Changed 20 months ago by dschnepper

  • Cc dschnepper@… added

Changed 20 months ago by dschnepper

Patch for 2.0.1

Changed 20 months ago by dschnepper

Patch for 3.0.1

comment:14 Changed 20 months ago by 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

comment:15 Changed 20 months ago by 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.

comment:16 Changed 20 months ago by 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.

comment:17 Changed 20 months ago by moo

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

comment:18 Changed 20 months ago by 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

comment:19 Changed 20 months ago by moo

  • PHP Version changed from 5.4.8 to 5.4.x

comment:20 Changed 20 months ago by 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

comment:21 Changed 20 months ago by moo

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:22 Changed 20 months ago by moo

confirmed fixed by dschnepper

backport as [1239] for branch 3.0.x

comment:23 Changed 20 months ago by moo

  • Milestone changed from undecided to 3.0.2

comment:24 Changed 16 months ago by gacek

This problem occurs also in PHP 5.2. I know, this version supported has been stopped by php.net, but i.e. 5.1 is still being supported by RedHat?/CentOS.

Is it possible to fix this bug also for ver <=5.2 ?
Simplest test case for this bug below. I know, this is dumb, but such construct is used by Zend Framework...

<?php
if (true) {

class My_Exception extends Exception {}

} else {

class My_Exception extends Exception {}

}
?>

comment:25 Changed 15 months ago by moo

no.

comment:26 Changed 14 months ago by specky_rum

Could you possibly provide an x64 Windows binary for the 3.1.0 release with this fix please? Specifically for PHP 5.4 thread safe. I'd like to give it another go. Cheers.

comment:27 Changed 14 months ago by moo

done, thanks for notifying me about missing x64 build

comment:28 Changed 14 months ago by specky_rum

This appears to be working beautifully now. Thanks very much!

Note: See TracTickets for help on using tickets.