XCache causes white screen of death
greg.harvey - December 2, 2008 - 13:19
| Project: | Cache Router |
| Version: | 6.x-1.0-beta8 |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | critical |
| Assigned: | slantview |
| Status: | closed |
Description
Hi,
Tried to implement XCache on our RHEL 5 dev server. The version used is XCache 1.2.1 with PHP 5.2.6. Instant white screen, as soon as you configure the Cache Router settings. Apache error log says:
[Tue Dec 02 13:07:24 2008] [notice] child pid 26256 exit signal Segmentation fault (11)Will try again with XCache 1.2.0 and report back. I appreciate this is probably not a bug with the Cache Router module, but it is worth documenting in case someone has the same issue. It would be good to get feedback of the maintainers too. =)
#1
Update: XCache 1.2.0 won't work with PHP 5.2.x except for 5.2.0 - we're running PHP 5.2.6. So it seems to me that XCache for the Drupal 6.x branch of Cache Router is a none-option right now... anyone else experiencing the same?
#2
I need to look into this. I deprecated the XCache module so I need to get this working.... Patches welcome ... :)
#3
Hi,
This could be down to RHEL 5 and running newer than recommended versions of nearly everything, rather than Cache Router. Unless you're seeing the same behaviour? Not sure what Cache Router can do about XCache causing an Apache segmentation fault though? =(
#4
@greg.harvey have you tried xcache 1.2.2? When I test this under centos 5 I build it from source and that works.
#5
Not yet. I'll find out what the sysadm guys want to do and if they still want to try opcode caching, we'll give it a try. Which version of PHP are you using though? With memcached that proved significant. We are using 5.2.6, which is not the usual for CentOS/RHEL.
#6
@greg.harvey we are using php and other from remi repo (blog.famillecollet.com/pages/Config-en)
This one from centos 4 server
php.i386 5.2.6-1.el4.remiphp-pecl-memcache.i386 3.0.2-1.el4.remi
#7
Cool... FYI, we used this to get PHP for RHEL 5:
http://www.jasonlitka.com/media/EL5/i386/
Did see the remi repo before, but opted for the above. Don't remember why. Probably no specific reason.
Our memcache RPMs look like this:
php-pecl-memcache-2.1.2-1.el5.rfmemcached-1.2.6-1.el5.pp
memcached came from here: http://drupal.org/node/341526#comment-1135634
And php-pecl-memcache-2.1.2-1.el5.rf is misleading, because we did a bad thing. To test, we just copied Ubuntu's PHP module over and it worked... naughty naughty!! =(
#8
Has there been any changes on this? i am having the same error in an ubuntu intrepid server.
Drupal 6.
PHP 5.2.6-2ubuntu4
Cache Router beta8
XCache 1.2.2-2
is there any performance differences between xcache and memcached? i thought xcache was supposed to be faster, but if xcache was depreciated because its not up to par then i will just switch to memcached
#9
They work in totally different ways - Xcache probably is quicker, but memcached is distributed so more scaleable and generic so you can use it for anything, not just PHP. Xcache only accelerates PHP (I think??)
#10
I'm getting a WSOD with a 500 error using Xcache (version 1.2.2, built from FreeBSD's ports collection). This seems to be caused by reading the data from the cache, because if I empty the cache from Xcache's admin pages (not this module's) or by restarting the web server, everything works fine for the first subsequent Drupal page load; it's only on the second when things go horribly, horribly wrong.
Here's my error log (I'm using Lighty):
2009-05-20 15:46:23: (mod_fastcgi.c.2494) unexpected end-of-file (perhaps the fastcgi process died): pid: 82399 socket: unix:/var/run/lighttpd/php-fastcgi.socket-02009-05-20 15:46:23: (mod_fastcgi.c.3326) response not received, request sent: 1224 on socket: unix:/var/run/lighttpd/php-fastcgi.socket-0 for /index.php , closing connection
2009-05-20 15:46:52: (mod_fastcgi.c.2494) unexpected end-of-file (perhaps the fastcgi process died): pid: 82399 socket: unix:/var/run/lighttpd/php-fastcgi.socket-0
2009-05-20 15:46:52: (mod_fastcgi.c.3326) response not received, request sent: 1199 on socket: unix:/var/run/lighttpd/php-fastcgi.socket-0 for /index.php , closing connection
…etc.
Has anyone out there managed to get this module to work with Xcache? I'd prefer to use Xcache because I'm already familiar with it, but I'll move to a different caching system if necessary. Either way, if Xcache compatibility with this module is simply broken, it'd be nice if that fact were stated on the project page…
#11
After further fiddling, I'm convinced this problem (or my iteration of it, anyway) is not caused by Cache Router, but by XCache itself - or at least something else on a lower level. This is because I can get the problem to occur by writing my own scripts calling xcache_get(), or by trying to load the variable through XCache's admin interface.
I've posted a thread on XCache's forum pleading for help. The main developer "moo" is usually pretty active there, so hopefully we'll get some answers, or at least some hints, soon.
#12
The issue seems to be related to the fact that xcache currently does not store object in variable cache. Attempting to get and store the object therefore is segfaulting the php process. Ref: http://xcache.lighttpd.net/wiki/XcacheApi
This patch should fix it for now by serializing everything. I think the memory handling can still use some work as it doesn't fail gracefully if insufficient var memory is available.
#13
Light testing with this patch has been successful so far. Thanks, janicel!
Does this mean that XCache has never worked as intended in Cache Router before?
#14
I honestly don't know. The code for xcache looks like it was adapted from the APC code. I suspect that the xcache portion was rarely used/tested and most people were using APC.
#15
$cache->serialized should be FALSE so change
<?php- if (!is_string($value)) {
- $cache->serialized = TRUE;
- $cache->data = serialize($value);
- }
- else {
- $cache->serialized = FALSE;
- $cache->data = $value;
- }
+ $data = serialize($cache);
?>
to
<?php- if (!is_string($value)) {
- $cache->serialized = TRUE;
- $cache->data = serialize($value);
- }
- else {
- $cache->serialized = FALSE;
- $cache->data = $value;
- }
+ $cache->serialized = FALSE;
+ $data = serialize($cache);
?>
Another issue with using $ttl parameter - drupal use 3 kinds: -1, 0, and time() + ttl
For xcache you should check $expire
<?phpif ($expire == CACHE_TEMPORARY) {
$ttl = 180;
}
elseif ($expire > 0) {
$ttl = $expire - time();
}
else {
$ttl = $expire;
}
...........
$cache->expire = $expire;
...........
// Attempt to store full key and value
if (!xcache_set($this->key($key), $cache, $ttl)) {
?>
#16
This should catch both of the issues you raised.
#17
after applying the patch I still got a WSOD.. hmm, anyone else having the same problem??
#18
Can you give a bit more details about your setup? Any message in the web server error log? How big is your xcache variable cache?
#19
Applied patch, may need a bit more testing to get XCache working correctly. It has definitely been the red-headed step-child of the group as it's hardly used. Will do more thorough testing to make sure this is actually working. Thanks for all the hard work on this!
#20
Automatically closed -- issue fixed for 2 weeks with no activity.
#21
rc1 with this patch aint no working =(
i still have error:
Fatal error: Call to undefined function xcache_get() in path/mysite.com/sites/all/modules/cacherouter/engines/xcache.php on line 35
dont know what to do.