|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58943 delete error
Submitted: 2009-11-10 17:58 UTC Modified: 2010-10-03 11:35 UTC
From: harv at pringo dot com Assigned: hradtke (profile)
Status: Closed Package: memcache (PECL)
PHP Version: 5.3.0 OS: linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: harv at pringo dot com
New email:
PHP Version: OS:


 [2009-11-10 17:58 UTC] harv at pringo dot com
CLIENT_ERROR bad command line format.  Usage: delete <key> [noreply]

With the latest version of memcache 1.4.3, the delete syntax that the extension is sending is invalid.  Extension is sending a 2nd parameter to memcache, and is failing to delete.

Simple fix:
memcache.c line 1494

// removes the 3rd param
command_len = spprintf(&command, 0, "delete %s", key);

Reproduce code:
$c = new Memcache();
$c->connect("", 11211);
var_Dump($c->set("cache_key", "testing delete"));

Expected result:

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-11-17 09:15 UTC] mkliewe at gmx dot de
We also have this error when deleting. We are using Ubuntu 9.10

Please fix this. Thanks.
 [2009-11-17 12:52 UTC] brad at bcs-mail dot net
We are also having the issue.  Will try the work around.
Centos 5.4
 [2009-11-18 11:08 UTC] dweller at devonweller dot com
I am also seeing this error on Centos 5.4 with memcache 1.4.3
 [2009-11-18 11:52 UTC] dweller at devonweller dot com
A patched version to workaround the delete bug is here:
 [2009-11-20 13:02 UTC] marc-bennewitz at arcor dot de
The protocol has been changed between 1.2 and 1.3:
  up to 1.2:
  # delete <key> <time> [noreply]\r\n

  since 1.3:
  # delete <key> [noreply]\r\n

and since memcached 1.4.3 the delete command will fail if a <time> was given.

Your patch doesn't work correctly: If you have a memcached 1.2.x the parameter '$timeout' will be ignored on Memcache::delete :(

To fix this check the server version first.
Do have have a patch for memcache 3.0.4, too?

-> I think the second parameter of Memcache::delete have to completely removed in the future.
 [2009-11-30 06:26 UTC] geoff at gosquared dot com
I'm seeing the same behaviour in beta versions > 2.2.5 stable, although these versions require a different patch to the one mentioned above for the stable version 2.2.5 

I have patched the problem in version 3.0.4. You can download the patched PECL memcache 3.0.4 from here:
 [2009-11-30 19:08 UTC] geoff at gosquared dot com
By the way, this issue should be resolved by a backwards compatibility fix in version 1.4.4 of memcached, obtainable over at
 [2009-12-17 07:09 UTC] johnd at librarything dot com
Please note that the 1.4.4 memcached release *doesn't* fix 
this problem if you were actually using the timeout option to 
delete in your code.  If that's the case, you'll need to 
change your code as well.
 [2010-01-08 04:03 UTC] darren at viamedia dot co dot za
Also having this issue on Mac OSX 10.6
memcache 2.2.5 stable
memcached 1.4.4

Works if I pass 0 as the timeout param but if anything greate than 0 is passed then it returns false.
 [2010-01-13 05:42 UTC] andrer at vg dot no
Yesterday I tested memcached 1.4.4 and was not able to delete anything. Turns out that pecl/memcache 3.0.4 defaults to timeout 1 for deletes instead of 0.

strace of PHP-process deleting a key without specifing timeout:
sendto(3, "delete user:1354381 1\r\n", 23, MSG_NOSIGNAL, NULL, 0) = 23

Specifing the timeout to 0 sends an proper command:
sendto(3, "delete user:1354381\r\n", 21, MSG_NOSIGNAL, NULL, 0) = 21

Turns out memcache.c uses "value" instead of "exptime" when running deletes and "value" is defaulted to 1(probably to be used with increment/decrement).

long value = 1, defval = 0, exptime = 0;
if (deleted) {
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z|l", &keys, &value) == FAILURE) {

Proposed fix:
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z|l", &keys, &exptime) == FAILURE) {
 [2010-02-05 11:44 UTC] scc1998 at hotmail dot com
The proposed fix from andrer is not complete, the delete 
functions deeper down in the function have to be changed 
from value to exptime:

static void php_mmc_numeric(INTERNAL_FUNCTION_PARAMETERS, 
int deleted, int invert) /*

if (mmc_object == NULL) {
    if (deleted) {
	if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, 
"Oz|l", &mmc_object, memcache_pool_ce, &keys, &exptime) == 

else {
    if (deleted) {
	if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, 
"z|l", &keys, &exptime) == FAILURE) {

if (Z_TYPE_P(keys) == IS_ARRAY) {
    while (zend_hash_get_current_data_ex(Z_ARRVAL_P(keys), 
(void **)&key, &pos) == SUCCESS) {
	zend_hash_move_forward_ex(Z_ARRVAL_P(keys), &pos);
	if (deleted) {
	    pool->protocol->delete(request, request->key, 
request->key_len, exptime);
else {
    if (deleted) {
	pool->protocol->delete(request, request->key, 
request->key_len, exptime);

NOTE: This is not the full function, just the parts that got 
value changed into exptime!
 [2010-02-20 00:42 UTC] dustin at spy dot net
This option has never worked on any version of memcached.  
Deletes have always been immediate.  Timeout means something 
entirely different from what it's documented to do.

All you have to do is try the existing code against an older 
version to verify that.

Applying this fix and adjusting the documentation to point out 
that it's unused and has never done what was intended is the 
right thing.
 [2010-03-24 00:32 UTC]
I will work with Pierre on the proper way to deal with BC breaks and get this fixed.
 [2010-04-11 00:44 UTC] ssuratku at yahoo dot com
I'm having the same problem.
FreeBSD 7.2
 [2010-04-21 00:35 UTC]
I added in the version checking code and then spent some time trying to create the bug.  However, I noticed that this BC break has been fixed in memcached-1.4.4: you can pass a value of 0 and the server will process the request as normal.

Since this is a 1.4.3 only issue, I am moving this ticket to won't fix.
 [2010-06-01 07:31 UTC] jimmywarhammer at gmail dot com
Sorry, today update our memcache servers from 1.2.8 to 1.4.5 and got those messages. Client version - 3.0.3
 [2010-06-01 10:59 UTC]
The backwards compatibility exists only for a timeout value of 0.

Consider the following example:
Connected to localhost.localdomain (
Escape character is '^]'.
set foo 0 60 1
delete foo
set foo 0 60 1
delete foo 0
set foo 0 60 1
delete foo 1
CLIENT_ERROR bad data chunk

Link to release notes:
 [2010-06-03 01:07 UTC] pizza at shaftnet dot org
Why is this marked as WONTFIX, when this is still a problem?  This code fails:

    $memcache = new Memcache;

....with the same CLIENT_ERROR:

[Thu Jun 03 00:28:30 2010] [error] [client] PHP Notice: 
MemcachePool::delete(): Server tcp://localhost:11211/ (tcp 11211, udp 0) failed
with: CLIENT_ERROR bad command line format.  Usage: delete <key> [noreply]\r\n
(0) in [.....]

How can this be considered anything but a regression?  This code used to work, now it doesn't.  All required arguments are present.

(pecl memcache 3.04 and memcached 1.4.5)
 [2010-06-03 11:36 UTC]
I was testing it on the 2.2.5 version.  I didn't realize that it was failing on the 3.0.x version.  I will fix it there then.
 [2010-06-14 13:13 UTC]
A patch was submitted in ticket #17566 that resolved the issue for the 3.0.x version.
 [2010-09-23 16:47 UTC] thedonk at gmail dot com
I'm still getting the same error using the same 3 lines of code mentioned by "pizza" above for:
memcached 1.4.5
pecl-memcache 2.2.5
ubuntu 9.04
 [2010-09-23 17:00 UTC] thedonk at gmail dot com
In fact, I'm getting it with pecl-memcache 3.0.4 beta as well.
 [2010-09-23 17:07 UTC] thedonk at gmail dot com
Sorry for getting a little bit spammy but it DOES seem to work for pecl-memcache 2.2.4
 [2010-10-03 11:35 UTC]
This bug has been fixed in SVN.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on

In case this was a website problem, the change will show
up on the website in short time.
Thank you for the report, and for helping us make PECL better.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Mon Oct 18 08:03:34 2021 UTC