Custom Query (267 matches)

At pfSense we are currently trying to integrate Xcache together with PHP 5.2.0. Unfortunatly XCache behaves quite unstable and causes lots of core dumps.

Disabling XCache, solves these issues.

I was able to track it down to the fact, that the following page allways results in a HTTP 500 if beeing saved and if using Xcache:

​http://pfsense.com/cgi-bin/cvsweb.cgi/pfSense/usr/local/www/system_advanced.php?rev=1.191;content-type=text%2Fx-cvsweb-markup

If trying to save the above page using EAccelerator I do not get a HTTP 500.

I even tried to use XCache v1.1.0 but the issue remains.

Enabled/Used? modules (in that order):

# add additional extensions below
extension=xcache.so
#extension=xdebug.so
extension=radius.so
#extension=suhosin.so
#extension=uuid.so

# standard PHP extension
extension=bz2.so
extension=bcmath.so
extension=ctype.so
extension=curl.so
extension=gettext.so
extension=mbstring.so
extension=pcntl.so
extension=posix.so
extension=session.so
extension=shmop.so
extension=sysvmsg.so
extension=sysvsem.so
extension=sysvshm.so
extension=tokenizer.so
extension=xml.so
extension=simplexml.so
extension=zlib.so

XCache config:

[xcache]
xcache.mmap_path = "/tmp/xcache"
xcache.cacher = On
xcache.size = 6M
xcache.stat = On
xcache.optimizer = On
auto_globals_jit = Off

Vbulletin 3.6.4 (security patched) RHEL4 php 4.4.5 xcache 1.0.3 (compiled from source -- you are missing this version in your ticket dropdowns)

Overall xcache is running excellent. However, I have had sporadic reports of users getting the following error when clicking a thread after using "new posts." I have also seen reports of this at vbulletin.com.

Fatal error: Direct instantiation of vB_Postbit class prohibited. Use the vB_Postbit_Factory class. in /includes/class_postbit.php on line 239

Here is a link of other reports of this error at vbulletin.com ​http://www.vbulletin.com/forum/showthread.php?t=215068

I also noticed when upgrading from vb 3.5.3 to 3.6.5 on another forum that there were some problems during the upgrade that never happened before xcache. May be unrelated. I had to disable xcache for moodle on one site (I'll make another ticket for that).

create a file is_a.php with contents:

# cat > is_a2.php <<EOF
<?php
class A {};
class B extends A {};
class C extends B {};
$b =& new B;
$c =& new C;
echo is_a($c, 'B');
EOF

# php -v
PHP 4.4.7-pl0-gentoo (cli) (built: May 24 2007 10:39:17)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
    with XCache v1.2.1, Copyright (c) 2005-2007, by mOo

# php is_a.php
Segmentation fault

# php -n is_a.php
1

With xcache, it always works, with xcache enabled, it usually breaks. Sometimes after moving the file it works the first or second time before breaking. Sometimes not.

/etc/php/cli-php4/ext/xcache.ini:

zend_extension=/usr/lib64/php4/lib/php/extensions/no-debug-non-zts-20020429/xcache.so
auto_globals_jit="0"
xcache.cacher="1"
xcache.size="10M"
xcache.count="2"
xcache.slots="8k"
xcache.var_size="0"
xcache.var_count="1"
xcache.readonly_protection="0"
xcache.mmap_path="/dev/zero"
xcache.stat="1"
xcache.optimizer="0"
xcache.coverager="0"
xcache.coveragedump_directory=""

Regardless of how xcache is disabled, it then works. Xcache breaks with php used via any of fast cgi, cli, or sapi with apache2. This breaks on both amd64 and x86. Both xcache versions 1.2.0 and 1.2.1 are affected.

All of these combinations break:
amd64/glibc 2.5/gcc 4.1.1
amd64/glibc 2.5/gcc 4.1.2
x86/glibc 2.5/gcc 4.1.2