lighttpd forum XCache > xcache_count sends php into loop

I just installed 1.2.1 and I cannot access the admin section.  I traced
it down to xcache_count(), which appears to just be causing the page to
reload itself (verified with a Warning error placed in the code, die()
statements, and renaming one of the includes() while the script is
running).  I'm not even sure where to start looking on this one... I
have confirmed that xcache is installed and appears to be running
properly...

Here's my ini settings...

extension = xcache.so


[xcache.admin]
xcache.admin.auth = On
xcache.admin.user = "user"
xcache.admin.pass = "md5(pass)" ;;Note, this is an actual md5 in my
php.ini

[xcache]
xcache.shm_scheme =        "mmap"
xcache.size  =                64M
xcache.count =                 4
xcache.slots =                8K
xcache.ttl   =                 3600
xcache.gc_interval =           0
xcache.var_size  =            64M
xcache.var_count =             4
xcache.var_slots =            8K
xcache.var_ttl   =             0
xcache.var_maxttl   =          0
xcache.var_gc_interval =     300
xcache.test =                Off
xcache.readonly_protection = Off
xcache.mmap_path =    "/dev/zero"
xcache.coredump_directory =   ""
xcache.cacher =               On
xcache.stat   =               On
xcache.optimizer =           Off

[xcache.coverager]
xcache.coverager =          Off
xcache.coveragedump_directory = ""

BTW, this is on CentOS5, php 5.2.2 FastCGI - Lighttpd...

can u get a backtrace of php when xcache_count is called and it died?

moo XCache wrote:
> can u get a backtrace of php when xcache_count is called and it died?

it never died... It just appears to refresh the page.  Basically sending 
php into a never ending redirect loop. I added a die statement to 
determine where the redirect was comming from...

Browser->request->index.php
index.php hits xcache_count
Browser->request->index.php
index.php hits xcache_count
Browser->request->index.php
index.php hits xcache_count

over and over ad_inifinium.

Anthony Ferrara wrote:
> moo XCache wrote:
>> can u get a backtrace of php when xcache_count is called and it died?
> 
> it never died... It just appears to refresh the page.  Basically sending 
> php into a never ending redirect loop. I added a die statement to 
> determine where the redirect was comming from...
> 
> Browser->request->index.php
> index.php hits xcache_count
> Browser->request->index.php
> index.php hits xcache_count
> Browser->request->index.php
> index.php hits xcache_count
> 
> over and over ad_inifinium.

Alright, I recompiled php in debug mode, and tried to get a backtrace. 
I verified that GDB was capturing errors by setting off a syntax error. 
When xcache.php goes into a loop, nothing is captured by GDB.  So there 
is no backtrace available... here's the thing.  I have duplicated this 
error on 2 of my servers.  Both are dual XEON IBM's with CentOS 5 and 
Lighttpd
Server 1 -
php:5.2.2 - FastCGI
gcc:4.1.1
Linux:2.6.18-8.1.3.el5 #1 SMP Mon Apr 30 19:55:44 EDT 2007 i686 i686 
i386 GNU/Linux

Server 2 -
php:5.2.3 - FastCGI
gcc:4.1.1
Linux:2.6.18-8.el5 #1 SMP Thu Mar 15 19:57:35 EDT 2007 i686 i686 i386 
GNU/Linux

Let me know if there is anything else I can give you...

> Alright, I recompiled php in debug mode, and tried to get a backtrace. 
> I verified that GDB was capturing errors by setting off a syntax error. 
what's that syntax error? can u paste the error message here?

error_log in php.ini might help too
log_errors = On
error_log = /tmp/phperr.log

moo XCache wrote:
>> Alright, I recompiled php in debug mode, and tried to get a backtrace. 
>> I verified that GDB was capturing errors by setting off a syntax error. 
> what's that syntax error? can u paste the error message here?
> 
> error_log in php.ini might help too
> log_errors = On
> error_log = /tmp/phperr.log

No, I set off a random synax error (I put in something like asdare(); 
and it returned a warning undefined function)...  The loop does not 
generate an error in itself.  It just recycles.

can u pls try httpwatch plugin (for ie), or firebug (for firefox)? i'm 
not sure what's going on. maybe u can pm me your url to 
phpxcache@gmail.com

moo XCache wrote:
> can u pls try httpwatch plugin (for ie), or firebug (for firefox)? i'm 
> not sure what's going on. maybe u can pm me your url to 
> phpxcache@gmail.com

It's sending it into a 401 redirect loop.


It's because I'm using 2 layers of HTTP authentication (the directory 
it's under has a HTTP auth that's different (digest) than xcache.  I 
tried disabling the xcache auth (in php.ini).  I tried setting my own 
config function that sets the xcache user/pass 
($_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'])...

I really need the prior level of http auth, so getting rid of that is no 
use... for a test, I placed the xcache directory outside of the 
protected directory and it works fine.

> It's because I'm using 2 layers of HTTP authentication (the directory 
> it's under has a HTTP auth that's different (digest) than xcache.  I 
> tried disabling the xcache auth (in php.ini).  I tried setting my own 
> config function that sets the xcache user/pass 
> ($_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'])...
still not working? why not try to move it out (as you described below) 
and see how to by-pass/disable XCache auth
> 
> I really need the prior level of http auth, so getting rid of that is no 
> use... for a test, I placed the xcache directory outside of the 
> protected directory and it works fine.

setting $_SERVER is better than disabling it which can be used by vhost 
users beside admin

moo XCache wrote:
> setting $_SERVER is better than disabling it which can be used by vhost 
> users beside admin

I think the problem is that I'm using digest authorization for the 
parent directory.  So when I get to xcache, it can't use the digest, so 
it spits a 401.  If I set the $_SERVER variables in xcache, the parent 
directory will spit a 401.  So it basically sends itself into an endless 
loop of 401's (the parent directory, then xcache, then the parent 
directory, etc)...  I wish there was a way to disable the auth all 
together... (APC makes it an option, not to compare).

you can set xcache.admin.enable_auth = off to disable it, but i don't 
guess it's different from setting $_SERVER

moo XCache wrote:
> you can set xcache.admin.enable_auth = off to disable it, but i don't 
> guess it's different from setting $_SERVER

We were working on that yesterday.  The setting was not working...