PHP v5.2.3 coredumps if using xcache r272 on pfSense HEAD

[DanielSHaischt]

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

[judas_iscariote]

can you provide a backtrace.. I cant reproduce your problem with "just" the file you are pointing us.

[DanielSHaischt]

Attached you will find the requested backtrace, which I got from the generated core dump.

BTW, the SVN revision I am using is r272 and *not* r727.

Further XCache infos:

Version 1.2-dev
Modules Built cacher optimizer
Readonly Protection N/A
Opcode Cache enabled, 6,291,456 bytes, 1 split(s), with 8192 slots each
Variable Cache disabled
Shared Memory Schemes malloc, mmap

Directive Local Value Master Value
xcache.cacher On On
xcache.coredump_directory no value no value
xcache.count 1 1
xcache.gc_interval 0 0
xcache.mmap_path /tmp/xcache /tmp/xcache
xcache.optimizer On On
xcache.readonly_protection 0 0
xcache.shm_scheme mmap mmap
xcache.size 6M 6M
xcache.slots 8K 8K
xcache.stat On On
xcache.test 0 0
xcache.ttl 0 0
xcache.var_count 1 1
xcache.var_gc_interval 120 120
xcache.var_maxttl 0 0
xcache.var_size 0 0
xcache.var_slots 8K 8K
xcache.var_ttl 0 0

[moo]

i'll try to look into it

can u pls do:

gdb> source ~/src/php5.2/.gdbinit
gdb> fr 1
gdb> dump_bt

btw. u don't have to put [[br]] all the way, use

{{{
preformanted text here
}}}

instead.

[moo]

and.. what's your sapi? apache+mod_php? lighttpd+mod_fastcgi->php-fcgi? or whatever?

[DanielSHaischt]

Replying to moo:

and.. what's your sapi? apache+mod_php? lighttpd+mod_fastcgi->php-fcgi? or whatever?

lighttpd-1.4.13+mod_fastcgi->php-fcgi

[DanielSHaischt]

Replying to moo:

can u pls do:
{{{
gdb> source ~/src/php5.2/.gdbinit
gdb> fr 1
gdb> dump_bt
}}}

You have to help me with the dump_bt. What should I provide to dump_bt as a 1st argument?

[moo]

sorry, it should be "zbacktrace"

[DanielSHaischt]

bt using PHP's .gdbinit

[judas_iscariote]

what happends if you set xcache.readonly_protection = On ??

[DanielSHaischt]

bt of core generated by /etc/sshd

[DanielSHaischt]

bt of core generated by /usr/local/www/system_advanced.php

[DanielSHaischt]

Replying to judas_iscariote:

what happends if you set xcache.readonly_protection = On ??

The HTTP 500 error still occures resulting from a php.core. Tho, the backtrace seems to be different. See attachment pfSense-xcache-system_advanced-bt.txt ...

I also attached a backtrace of /etc/sshd which is another PHP script meant to start sshd while booting the system.

[moo]

it's quite odd to see cache->lck == NULL ...

[DanielSHaischt]

Replying to moo:

it's quite odd to see cache->lck == NULL ...

want me to give you access to the box (tho, it will be a stupid german DSL 384 connection)? So you may debug the issue on you own...

[moo]

yeah, but before that, do me a strace

strace /etc/sshd

and send me the account to phpxcache@…

[DanielSHaischt]

strace output of /etc/sshd (PHP script)

[DanielSHaischt]

truss(1) output of /etc/sshd (PHP script)

[moo]

by reading your etc_shd_strace.out

open("/tmp/xcache", O_RDWR)             = 4
ftruncate(4, 6291456)                   = 0
mmap(0, 6291456, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0x289da000
mmap(0, 6291456, PROT_READ, MAP_SHARED, 4, 0) = 0x28fda000
close(4)                                = 0
gettimeofday({0, 0}, NULL)              = 0
getuid()                                = 0 (euid 0)
open("", O_RDWR|O_CREAT, 0666)          = 4
unlink("") 

open(""...) is wired, while etc_sshd_strace.out looks fine

can u pls do

set | grep TMPDIR
set | grep TMP

before u can start /etc/sshd and make sure it still crash in such env, the way u made in etc_sshd_strace.out not etc_sshd_truss.out. we're closer to the xcache problem on sshd.

if u know how to gdb, try:

gdb> br lock.c:102
gdb> r
gdb> p pathname

[moo]

pls ignore my last note asking u gdb it.

alloca problem is fixed in [282], can u pls verify if it fix sshd and/or pfSense problem?

[DanielSHaischt]

Replying to moo:

alloca problem is fixed in [282], can u pls verify if it fix sshd and/or pfSense problem?

At the moment I am not getting any core dumps with the fix from [282] any more. Other pfSense devs did stop reporting core dumps as well. So maybe it's time to close this ticket?

[moo]

ok, let's assume that is fixed in [282]

[DanielSHaischt]

okay this issue still persist.

PHP core files:

 http://dev.pfsense.untouchable.net/php-xcache-cores.tar.gz

Trace:

 http://dev.pfsense.untouchable.net/xcache.php.core.txt

Recent pfSense ISO:

 http://snapshots.pfsense.com/FreeBSD6/head/iso/

[moo]

try 1.2.1 pls

[moo]

btw, i need your php-fcgi, xcache.so and processor_real.c (generated when building XCache)

[trac-robot]

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.