[Advisory] Old PHP client very buggy...

[Sean Chittenden]

I know it's late for a Halloween story, but save it so you can pull it 
out next year during October and scare some php kiddies.  Running 
across this bug was spooky and hard to diagnose.

I'd like to advise all users of the native PHP client distributed by 
Danga to use the client posted by Timo Ewalds (plus the patch from Ian 
Kallen).  The URL for the original PHP client  in question is:

http://www.danga.com/memcached/dist/php-memcached-1.0.10.tar.gz

I'm pretty sure they didn't write it, but since it's distributed by 
danga.com, many folks get the wrong impression that it's the 
authoritative or recommended client to use.  The URL for the updated 
client and its patch is:

http://lists.danga.com/pipermail/memcached/2004-December/001004.html
http://lists.danga.com/pipermail/memcached/2004-December/001008.html

The original PHP client is subject to an effective DoS wherein its 
parsing of data from the memcached server was buggy and would cause the 
client to hang forever.  Timo's updated client doesn't suffer from this 
grave problem.

Many users may not be bitten by this, but, if all of a sudden pages 
start hanging, or there's a slow creeping growth of apache processes, 
the likely culprit is this memcached client.  Other symptoms include 
maxing out database connections or other resources that apache may use, 
but never release because the request never reaches the cleanup state.

This particular bug is hard to track if someone attaches ktrace(1) or 
gdb(1) to the idle apache process, which is just that: completely idle.

I consider this to be a bug on PHP's socket implementation as well, not 
just a bug in the original php memcached client.  Apache's client 
timeout is ignored when doing PHP's socket IO, which is rather bogus.  
The client timeout in apache should be read by php and applied to all 
socket IO when socket IO is performed via apache/mod_php, which would 
prevent an infinite growth of apache processes and resource consumption 
(database or otherwise).  Having PHP do this for non-mod_php requests, 
however, would be undesirable.

I haven't spent the time to look at why this is, only to suggest that 
someone may want to either sit down and figure out where the problem is 
with the above PHP client mentioned above or upgrade to Timo's version. 
  The only notable difference between the clients insofar as I have 
noticed is the class name needs to be changed.

FWIW, I likely won't be spending much more time with the native PHP 
client and will probably be adding libmemcache(3) support to the PEAR 
version which would give the PEAR version multi-server support.  
Anyway, have a nice day.  -sc

-- 
Sean Chittenden