>memcached 1.1.12 and 
Please downgrade memcached to the previous version, this version is known to have protocol violations.

>libmemcache-1.4.0rc2.
Erm.. Are you sure you are using PECL/memcache?
If so, why do you mention libmemcache, which has nothing to do with this extension?

>Please downgrade memcached to the previous
>version, this version is known to have protocol
>violations.

I followed this suggestion, and the same behavior persists. I also upgraded to memcached-1.1.13-pre2, which also has the same issues.

Can you provide more information (a link?) regarding the 1.1.12 protocol violation bugs? I couldn't find anything about that, and the 1.1.13-pre2 ChangeLog doesn't mention fixing any protocol violations either ... so it may be worth escalating this to Brad Fitzpatrick to resolve these issues in 1.1.13.

>Erm.. Are you sure you are using PECL/memcache?
>If so, why do you mention libmemcache, which has
>nothing to do with this extension?

Ah, sorry about that -- have all my memcache related libs downloaded to one source dir, and forgot that only lighttpd is using libmemcache. Please disregard.

The connection shouldn't be disconnected until script shutdown. If for some reason the server closes the connection immediatly after the first set() as your trace indicates, futher calls to set() and get() should and will indeed fail (and returning false.) 

Running example.php against memcached 1.1.12 using -vv output the expected values and produces as trace as:

<3 server listening
<7 new client connection
<7 set str_key 0 0 28
>7 STORED
<7 set num_key 0 0 3
>7 STORED
<7 set obj_key 1 0 46
>7 STORED
<7 set arr_key 1 0 44
>7 STORED
<7 get str_key
>7 sending key str_key
>7 END
<7 get num_key
>7 sending key num_key
>7 END
<7 get obj_key
>7 sending key obj_key
>7 END
<7 connection closed.

The question is then why your server closes the connection unexpectedly after the first set()? Could it be some OSX or PHP 5.2 related issue?

//Mikael

It appears that this is specifically an issue related to ext/memcache (or memcached itself) on Mac OS X.

I ran example.php this evening on my CentOS 4 server with ext/memcache 2.0.4 and memcached 1.1.12, and it ran as expected without errors.

What information can I provide to help determine where the issue is (and with which package) on Mac OS X?

First verify whether the problem lies in memcached itself or pecl/memcache by telnetting (e.g. "telnet localhost 11211") to the deamon and issuing the commands:

set str_key 0 0 28
String to store in memcached

The server should then respond with "STORED" and, if the problem lies with memcached itself, close the connection (whereby telnet outputs "Connection closed by foreign host.")

If the problem lies with memcached you should contact the package maintainer and possibly the memcached mailing list (memcached@lists.danga.com). You might want to attach a trace by starting memcached like "strace memcached -u nobody -l 127.0.0.1 -p 11211" with the telnet session running from another terminal.

However, if the problem lies with pecl/memcache please attach a trace by running example.php like "strace php example.php"

//Mikael

I had exactly the same issue (on PHP 5.1.2, Mac OS X 10.4.7)
Recompiling memcached after applying the patches described in this build-script fixed the problem for me.

http://topfunky.net/svn/shovel/memcached/install-memcached.sh

Seems like this is a problem with memcached itself (judging by the last comment by marco at kaywa dot com) which should be brought to the memcached mailing list instead.