yibaini / memcached Goto Github PK

Patch from Domas:
if (daemonize) {
   signal(SIGHUP,SIG_IGN);
}

Some (old?) versions of the "tr" command don't interpret '\t' as "tab"
-rather it is read as the letters "\" and "t".
I've found that using the tab key, not the "tab" character "\t" always
seems to work. 
Under the "memcached_dtrace.h" target in Makefile I substituted tr '\t' ' '
with tr '    ' ' '. where I used the tab key between the first two '
charachters. It would be nice if someone could shed light on why "\t"
wouldn't always work.

memcached_dtrace.h: memcached_dtrace.d
        ${DTRACE} -h -s memcached_dtrace.d
        sed -e 's,void \*,const void \*,g' memcached_dtrace.h | \
            sed -e 's,char \*,const char \*,g' | tr '\t' ' ' > mmc_dtrace.tmp
        mv mmc_dtrace.tmp memcached_dtrace.h

changed to

memcached_dtrace.h: memcached_dtrace.d
        ${DTRACE} -h -s memcached_dtrace.d
        sed -e 's,void \*,const void \*,g' memcached_dtrace.h | \
            sed -e 's,char \*,const char \*,g' | tr '    ' ' ' > mmc_dtrace.tmp
        mv mmc_dtrace.tmp memcached_dtrace.h

There's a growing number of "extended" options that I think could be added.
 Code's been written for this, so it just needs to go one way or the other.

The current work can be found here:

http://github.com/dustin/memcached/commits/oparam

It is not possible to issue a storage command without expecting a message
back (the noreply flag in the textual protocol).

we should create q versions like we did for get.

The binary protocol version has added test code coverage (gcov, tcov) to
the memcached-debug binary. When running "make test" the first test,
00-startup, will hang for approx. 30 secs. This only happens with gcov (not
tcov). The 00-startup test starts two memcached instances and when the test
is finished both instances will receive SIGINT at the same time. The gcov
processing taking place simultaneously in both memcached instances before
exit makes the processes hang. One possible fix is to send SIGINT to the
first memcached instance before starting up the next instance.

In 00-startup.t 
add the line "kill 2, $server->{pid};" :

#!/usr/bin/perl

use strict;
use Test::More tests => 3;
use FindBin qw($Bin);
use lib "$Bin/lib";
use MemcachedTest;

my $server = new_memcached();

ok($server, "started the server");
kill 2, $server->{pid};

eval {
    my $server = new_memcached("-l fooble");
};
ok($@, "Died with illegal -l args");

eval {
    my $server = new_memcached("-l 127.0.0.1");
};
is($@,'', "-l 127.0.0.1 works");

static void usage(void) {
.
.
INDRR_ANY

should be :

INADRR_ANY

Just from eyeballing the code, I think the accept_new_conns() function (new
connection throttling) might not work.

accept_new_conns(false) is called by the listen thread when there aren't
enough file descriptors.  Later, in conn_close(), the code calls
accept_new_conns(true) since closing a connection releases a file descriptor.

But, there's a sanity check in accept_new_conns(), line 3079...

    if (! is_listen_thread())
        return;

I haven't written a test or proven it live, but I think that
accept_new_conns(true) never really works because of that check.  Meaning
once memcached stops accepting new connections, it never starts accepting
new connections anymore.

We need a description for:
-C - Disable use of cas
-R - Number of requests processed per event

hi, i want to know memcached installation steps for Drupal.
if you have any suitable link, or some thing please provide me, 
memcache server is running, but it's not working for drupal. "What is this
PECL".

Kamlesh Patidar 

In the binary protocol version:
At the end of the function process_bin_stat there is a memset command that
uses strlen on a buffer that is not null-terminated. This causes writes
past the end of the buffer and memcached to malfunction or hang sometimes. 

Solution:
1)
Just removing the memset seems to work fine.

or alternatively

2)
Change
        memset(subcommand, 0, strlen(subcommand));
To
        memset(subcommand, 0, nkey);


process_bin_stat:

.
.
.
    } else {
        int len = 0;
        buf = get_stats(subcommand, nkey, &append_bin_stats, (void *)c, &len);
        memset(subcommand, 0, strlen(subcommand));

        /* len is set to -1 in get_stats if memory couldn't be allocated */
        if (len < 0)
            write_bin_error(c, PROTOCOL_BINARY_RESPONSE_ENOMEM, 0);
        else if (buf == NULL)
            write_bin_error(c, PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 0);
        else
            write_and_free(c, buf, len);
    }
}

Brad Fitzpatrick did some work on verifying the data being incremented and
decremented as well as the delta parameters.

I've brought it back up to master and have it mostly ready -- just waiting
for review.

http://github.com/dustin/memcached/tree/incr_fix

I tried to modify my log4j.xml to turn the logging for memcached off.
The only thing that seemed to turn it off was 
<category name="STDERR"><priority value="OFF"/></category>

That shut off alot of things though.
Is there a way I can just shut the log messages off for the memcached?

[deleted issue]

append_bin_stats cast a char pointer into a pointer to a structure, but the
problem is that such a structure needs to be aligned in order to access its
members.

We are currently spooling up a lot of data to send back to the client so we
cannot pad the buffer in order to align the structure. A quick fix is to
fill in a local structure and memcpy it into the stream.

typedef protocol_binary_response_no_extras protocol_binary_response_nnoop;

should be :

typedef protocol_binary_response_no_extras protocol_binary_response_noop; 

What steps will reproduce the problem?

<?php
$memcache = new Memcached;
$memcache->addServer('127.0.0.1',11211);
$k = 'membugtest';
$memcache->delete($k);
$memcache->add($k,'string');
var_dump($memcache->get($k));
$memcache->delete($k,3600);
var_dump($memcache->get($k));


What is the expected output? What do you see instead?
First time the output is:
   string(6) "string"
   bool(false)
Next times:
   bool(false)
   bool(false)
Excepted output is the following at any time:
   string(6) "string"
   string(6) "string"

What version of the product are you using? On what operating system?
Memcached 1.2.6 under FreeBSD.

http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol

getk/getkq response example:

Total body   (8-11) : 0x00000009

Total body len should be 14 bytes, not 9 bytes 

What steps will reproduce the problem?

1. placed the attached prove test (udpBinary.t) into <WORKSPACE_ROOT>/t

2. run the test 

3. note that 'select' operations times out while waiting for I/O from the 
server and then test 
hangs

smacky:memcached elambert$ prove t/udpBinary.t 
t/udpBinary....ok 1/12                                                       
#   Failed test 'got readability'
#   in t/udpBinary.t at line 120.
t/udpBinary....NOK 2^C   

(NOTE, the attached test is not really ready for prime time as basically all it 
does is check that 
server has i/o to send back and then reads the i/o if there is some. The test 
will be improved to 
do more, so probably should not be added to the source tree for the time 
being). 

What is the expected output? What do you see instead?

The test should not fail waiting on I/O from the server, the test should not 
hang.

(Tagging this as high priority since the 1.3.2 release is supposed to be the  
official binary 
protocol release and probably best that binaryUDP work since ASCII udp works, 
but clearly this is 
not a regression --since binary was not avail in the 1.2.6-- and as such I 
would not fight 
downgrading the priority)

From [email protected]         

Still playing with slabs allocation, I found another strange result.
Storing only one small value in memcached, I end up with this output
for stats slabs:

STAT 1:chunk_size 104
STAT 1:chunks_per_page 10082
STAT 1:total_pages 1
STAT 1:total_chunks 10082
STAT 1:used_chunks 10082
STAT 1:free_chunks 0
STAT 1:free_chunks_end 10081
STAT active_slabs 1
STAT total_malloced 1048528

It is strange that whereas I store only one value, used_chunks report
10082. However, after deleting the value, free_chunks increase to 1,
and used_chunks decrease to 10081. Why are chunks in free_chunks_end
also considered as used_chunks ?

I have an easy fix, but I need to write a test for it.

Should we add a command line option to disable the flush command?

What steps will reproduce the problem?
1. compile
2. ???
3. profit

Reported on the list - dear self: Don't forget to build test on openbsd,
yeesh. Not detecting some of the new ipv6 variables correctly.

  Basically, it appears that the integrity of 'cas' is tainted.  Both 
the 'incr' and 'decr' operations do not update the cas ID of the key. 
I realize that this is a fringe case, but I think for something like 
'cas' to be effective and reliable, it needs to stay true to its 
principal.  I should be guaranteed that when the cas command accepts 
my update, that I am replacing the value I think I am.  See below for 
an example of the current behavior: 

set test 0 0 1 
0 
STORED 
gets test 
VALUE test 0 1 2   # CAS ID is 2 
0 
END 
incr test 1 
1 
gets test 
VALUE test 0 1 2   # CAS ID is still 2, despite the key's value 
changing 
1 
END 
cas test 0 0 1 2 
9 
STORED              # This would've succeeded no matter when I got 
that 
cas ID.  It's useless. 
gets test 
VALUE test 0 1 3 
9 
END 

binary protocol version:

get command increments refcount but doesn't decrement after command is
finished. The item cannot be evicted after this.

Works if adding a few lines to reset_cmd_handler function but not sure if
this is 100% fixing refcount problem in binary protocol version

static void reset_cmd_handler(conn *c) {
    if (c->item != NULL) {
        item_remove(c->item);
        c->item = 0;
    }

The current maximum key length limit (250 bytes) should be dropped
altogether, because it is artificial and arbitrary, and because it
complicates the usage of memcached unnecessarily.

As far as it concerns the code of memcached, the limit is purely artificial.

There may be reasons for having a small key length (speed; memory
consumption), but there may also be reasons for a large key length
(correctness (exact match vs. match of hash values); ease of use (no need
for workarounds around key lengths limits); ease of debugging (see keys in
cleartext, not as hashed text); less surprises when the limit is reached
only occasionally). Thus, memcached should not decide a priory on an
arbitrary limit.

Clients (and servers, too) are are allowed to warn about inefficiencies
pertaining to key length (e.g. if the key length exceed 250 bytes), but
they should continue to work if they can, and they can.

Thus, the limit should be dropped from the server as well as from the protocol.

To reproduce, start a telnet to memcached...

> set a 0 0 1
> 1
STORED
> incr a 10000
10001
> get a
VALUE a 0 5
10001
END
> decr a 10000
1
> get a
VALUE a 0 5
1    
END

The number of bytes after the big decr is 5, and perhaps it should be 1. 
For example...

> get a
VALUE a 0 1
1
END

Details of the -D parameter is not included in the usage() output.

The binary protocol tries to cast the rcurr pointer to a structure and
dereference the structure. This does not work very well if rcurr points to
an unaligned address. This will only occur if you are pipelining multiple
commands so that read may return data for more than one memcached command.

The introduction of the -b parameter broke the -C parameter and didn't
properly handle the argument of -b

I've fixed this with a test atop the "stats settings" change and used that
feature to verify the effect, but it may need to be backported if the
community has issues with "stats settings".

__What steps will reproduce the problem?__
1. Start memcached with a big memory limit (e.g. -m 1024)
2. Populate this memcached instance with a rate of 1 MB per second, where
each item has a validity timeout of 16 seconds. Use random strings or
numbers as keys.

__What is the expected output?__
It is expected that the memory allocated by memcached is about 16 MB (+some
overhead), because after filling memcached with 16MB worth of data, the
items start to become invalid, thus, the rate of items becoming invalid is
the same as the rate of new items. Thus, the amount of memory needed
remains rougly 16MB.

__What do you see instead?__
The memory allocated by memcached increases, until reaching a limit at
around 1024MB. Thus, memcached consumes much more memory than needed.
Memcached should be conservative with memory, and free old (invalid) items
first before requesting new memory from the operating system.

__What version of the product are you using? On what operating system?__
memcached 1.2.2 on Linux 2.6.18-6-amd64

__Please provide any additional information below.__

What steps will reproduce the problem?
1. memcached jars for java application
2. make connection with memcached server
3. set Key-value pair memcached server

connection successfull but server sends response as Error and that's 
console prints log as STDERR

2009-03-06 09:17:24,187 ERROR [STDERR] 2009-03-06 09:17:24.187
2009-03-06 09:17:24,187 ERROR [STDERR]  
2009-03-06 09:17:24,187 ERROR [STDERR] INFO
2009-03-06 09:17:24,203 ERROR [STDERR]  
2009-03-06 09:17:24,203 ERROR [STDERR] 
net.spy.memcached.MemcachedConnection
2009-03-06 09:17:24,203 ERROR [STDERR] :  
2009-03-06 09:17:24,203 ERROR [STDERR] Added {QA 
sa=jjoshi.asite.asitehq.com/192.168.100.94:11211, #Rops=0, #Wops=0, #iq=0, 
topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2009-03-06 09:17:24,218 ERROR [STDERR] 2009-03-06 09:17:24.203
2009-03-06 09:17:24,218 ERROR [STDERR]  
2009-03-06 09:17:24,218 ERROR [STDERR] INFO
2009-03-06 09:17:24,218 ERROR [STDERR]  
2009-03-06 09:17:24,218 ERROR [STDERR] 
net.spy.memcached.MemcachedConnection
2009-03-06 09:17:24,218 ERROR [STDERR] :  
2009-03-06 09:17:24,218 ERROR [STDERR] Connection state changed for 
sun.nio.ch.SelectionKeyImpl@f0e58b


how to configure memcache server to send responce as DEBUG...

What steps will reproduce the problem?
1. add "-D ALLOW_SLABS_REASSIGN" to CFLAGS
2. compile

with gcc-3.5 you will see warnings, but it does compile:
slabs.c: In function `do_slabs_reassign':
slabs.c:373: warning: use of cast expressions as lvalues is deprecated
slabs.c:403: warning: use of cast expressions as lvalues is deprecated

but with gcc-4 you will see a compile error:
slabs.c: In function 'do_slabs_reassign':
slabs.c:373: error: invalid lvalue in assignment
slabs.c:403: error: invalid lvalue in assignment

tried with 1.2.6 and 1.2.8. same error.

I'm using the standard Debian Lenny package for memcached version 1.2.2-1

1.) Client connects to memcached
2.) Client writes "set foo 0 10 3\r\nbar\r\n" to the output stream
3.) Client closes the output stream
4.) Client reads from the input stream
5.) Client closes connection

About 1 in 10 of these I don't get a response and the data isn't stored. I
think it's a race condition caused by memcached thinking that because I
closed the output stream that means I closed the socket?

You could say that I should just remove step 3 from my code but I'm
actually using a configuration option of a third party application (the
Exim mail server) so it's not my own code...

Steps to reproduce:
weirdan@virtual-debian:/home/sam/trunk/test/unit$ echo $((2**63-1))
9223372036854775807
weirdan@virtual-debian:/home/sam/trunk/test/unit$ telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
stats
STAT pid 590
STAT uptime 84394
STAT time 1235062054
STAT version 1.2.6
STAT pointer_size 32
STAT rusage_user 0.220013
STAT rusage_system 3.184199
STAT curr_items 683
STAT total_items 7293
STAT bytes 293187
STAT curr_connections 6
STAT total_connections 503
STAT connection_structures 16
STAT cmd_get 15597
STAT cmd_set 7291
STAT get_hits 8319
STAT get_misses 7278
STAT evictions 0
STAT bytes_read 7525934
STAT bytes_written 7270772
STAT limit_maxbytes 67108864
STAT threads 1
END
set aaa 0 0 19
9223372036854775807
STORED
get aaa
VALUE aaa 0 19
9223372036854775807
END
incr aaa 1
9223372036854775808
incr aaa 1
9223372036854775809
decr aaa 1
0
quit
Connection closed by foreign host.
weirdan@virtual-debian:/home/sam/trunk/test/unit$


Expected output:
decr should return 9223372036854775808


Memcache Version 1.2.6, running on debian linux 32bit, compiled with:
weirdan@virtual-debian:/home/sam/trunk/test/unit$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-3' --
with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-
languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-
system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-
threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --
program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-
objc-gc --enable-mpfr --enable-targets=all --enable-cld --with-tune=generic 
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --
target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Debian 4.3.3-3)


The reason for this problem seems to be on this line: 
http://consoleninja.net/gitweb/gitweb.cgi?
p=memcached.git;a=blob;f=memcached.c;h=3b7a187f726d4eb6ca5ae9684a3edaca984f
e58b;hb=HEAD#l1580

1580         if (delta >= value) value = 0;

where signed long long int delta is compared to unsigned long long value.

memcached-tool does not display evicted items.
also it has a slightly odd display if the memcache is quite big (some GB)
and has long holding times.

this diff here helps in both cases.

the server_stats function allocates a 1024 buffer to hold the stats as it 
collects them. A ptr called 
pos is used to track the location in the buffer and to write new data into the 
buffer. We increment 
the pointer as we move along but do not protect against *pos going off the end 
of the buffer. See 
code below

static char *server_stats(uint32_t (*add_stats)(char *buf, const char *key,
                          const uint16_t klen, const char *val,
                          const uint32_t vlen, void *cookie), conn *c,
                          int *buflen) {
    char temp[1024];
    char val[128];
    char *buf = NULL;
    char *pos = temp;
....
    vlen = sprintf(val, "%lu", (long)pid);
    nbytes = add_stats(pos, "pid", strlen("pid"), val, vlen, (void *)c);
    pos += nbytes;
    *buflen += nbytes;

  I've been thinking about a "stats settings" that effectively dumps
the settings struct.  It helps in those cases where someone is asking
questions and you want to know something about their config.

  It also helped to write tests for the -C and -b: arguments that got
messed up specifically (as pointed out by Clint Webb).  I was able to
write a simple startup test that verifies that -C properly sets the
CAS setting where we want it, and -b: properly sets the tcp backlog
where we want it.

  stats settings, documentation and tests are in my stats_settings
branch and visible here:

    http://github.com/dustin/memcached/commit/0a83f5235d754543f602bc1aa67...

  The option tests and fixes are here:

    http://github.com/dustin/memcached/commit/d038aa38b8bfc4ae5abbe007929...

  In introducing these, I noticed that we are a bit hopeful in buffer
sizes when processing stats (as we need to do proper protocol-specific
termination).  Overall, I think the stats code may need a bit of work
to be safer, but this particular code is no worse. 

function: process_bin_stat :
.
.
    } else if (strncmp(subcommand, "detail", 6) == 0) {
.
.
.
        if (strncmp(subcmd_pos, " dump", 5) == 0) {
.
.
.
            bufpos = buf;

            nbytes = append_bin_stats(bufpos, "detailed",
strlen("detailed"), dump_buf, len, (void *)c);
            bufpos += nbytes;
            nbytes += append_bin_stats(bufpos, NULL, 0, NULL, 0, (void *)c);


The last append_bin_stats command writes past the end of "buf" and causes
memcached to crash or hang sometimes. Just removing this command is the
solution?

The textual protocol does not allow stale data to persist in the cache in
case of memory allocation errors. The binary protocol allows it.

e.g:

Textual protocol:
////////////////////////
static void process_update_command(conn *c, token_t *tokens, const size_t
ntokens, int comm, bool handle_cas) {
.
.
.
    it = item_alloc(key, nkey, flags, realtime(exptime), vlen+2);

    if (it == 0) {
        if (! item_size_ok(nkey, flags, vlen + 2))
            out_string(c, "SERVER_ERROR object too large for cache");
        else
            out_string(c, "SERVER_ERROR out of memory storing object");
        /* swallow the data line */
        c->write_and_go = conn_swallow;
        c->sbytes = vlen + 2;

        /* Avoid stale data persisting in cache because we failed alloc.
         * Unacceptable for SET. Anywhere else too? */
        if (comm == NREAD_SET) {
            it = item_get(key, nkey);
            if (it) {
                item_unlink(it);
                item_remove(it);
            }
        }
        return;
    }
.
.
.
}

Textual protocol:
////////////////////////

int do_store_item(item *it, int comm, conn *c) {
.
.
.
        if (comm == NREAD_APPEND || comm == NREAD_PREPEND) {
.
.
                new_it = do_item_alloc(key, it->nkey, flags,
old_it->exptime, it->nbytes + old_it->nbytes - 2 /* CRLF */);

                if (new_it == NULL) {
                    /* SERVER_ERROR out of memory */
                    if (old_it != NULL)
                        do_item_remove(old_it);
                    return 0;
                }
.
.
.
}

Binary protocol:
////////////////////////
static void process_bin_update(conn *c) {
.
.
.
    it = item_alloc(key, nkey, req->message.body.flags,
            realtime(req->message.body.expiration), vlen+2);

    if (it == 0) {
        if (! item_size_ok(nkey, req->message.body.flags, vlen + 2)) {
            write_bin_error(c, PROTOCOL_BINARY_RESPONSE_E2BIG, vlen);
        } else {
            write_bin_error(c, PROTOCOL_BINARY_RESPONSE_ENOMEM, vlen);
        }
        /* swallow the data line */
        c->write_and_go = conn_swallow;
        return;
    }
.
.
.
}

Binary protocol:
////////////////////////
static void process_bin_append_prepend(conn *c) {
.
.
.
    it = item_alloc(key, nkey, 0, 0, vlen+2);

    if (it == 0) {
        if (! item_size_ok(nkey, 0, vlen + 2)) {
            write_bin_error(c, PROTOCOL_BINARY_RESPONSE_E2BIG, vlen);
        } else {
            write_bin_error(c, PROTOCOL_BINARY_RESPONSE_ENOMEM, vlen);
        }
        /* swallow the data line */
        c->write_and_go = conn_swallow;
        return;
    }
.
.
.
}

file: memcached.c
function: static void process_bin_stat(conn *c)
defect code: } else if (strcmp(subcommand, "reset") == 0) {
correct code: } else if (strncmp(subcommand, "reset", 5) == 0) {

They are currently installed if you run make install

The "stats reset" command doesn't clear the data from "stats items".  Don't
know if it should?

What steps will reproduce the problem?

1. apply the attached patch (udp.t.diff) to t/udp.t  

2. run the udp test (prove ./t/udp.t)

What is the expected output? What do you see instead?

-Expected: All tests should pass

-Actual: the set test fails and hangs


What version of the product are you using? On what operating system?

-1.3.2. running on Mac OS X (10.5.6) 


Please provide any additional information below.

-The problem appears to be due to the fact that the complete_nread() function 
does not handle 
the udp protocol (c->protocol == ascii_udp_protocol). Already have a patch, 
will submit it to 
the mailing list. 

-FWIW, glancing at the code suggest that there is no support for any UDP 
operations using 
binary protocol. Will create a test and file a bug as appropriate.

With memcached 1.3.x, for the binary protocol,
incrementing/decrementing a non-number incorrectly gives you a success
response and 0 (numeric 0) value.  In the ascii protocol, for
comparison, you get an error "CLIENT_ERROR cannot increment or
decrement non-numeric value".

It looks like the complete_incr_bin() function in memcached.c that
calls add_delta() is ignoring add_delta()'s return value, and also
looks like it's using an uninitialized stack buffer.

Using Dustin's python test framework
(http://github.com/dustin/memcached-test)...

    def testIncrNonNumber(self):
        """Test incrementing a non-number value."""
        self.mc.set("x", 0, 0, "text")
        val, cas = self.mc.incr("x")
        print(val) # This prints 0 rather than raising an error.

Partial output from running memcached in -vvv mode...

30: going from conn_read to conn_parse_cmd
<30 Read binary protocol data:
<30    0x80 0x05 0x00 0x01
<30    0x14 0x00 0x00 0x00
<30    0x00 0x00 0x00 0x15
<30    0x00 0x00 0x00 0x00
<30    0x00 0x00 0x00 0x00
<30    0x00 0x00 0x00 0x00
30: going from conn_parse_cmd to conn_nread
incr x 1, 0, -1
> FOUND KEY x
>30 Writing bin response:
>30   0x81 0x05 0x00 0x00
>30   0x00 0x00 0x00 0x00
>30   0x00 0x00 0x00 0x08
>30   0x00 0x00 0x00 0x00
>30   0x00 0x00 0x00 0x00
>30   0x00 0x00 0x00 0x09

What steps will reproduce the problem?
1. Everytime the cache does not contain the expected data length

What is the expected output? What do you see instead?
the python module should send an _Error exception:
Read %d bytes, expecting %d, read returned 0 length bytes
but instead, we have this one:
python_memcached-1.43-py2.6.egg/memcache.py", line 913, in recv
TypeError: %d format: a number is required, not str

What version of the product are you using? On what operating system?
not related to memcached himself. The issue comes from python-memcache-1.43

Please provide any additional information below.
to fix, I guess you should replace in line 913:
'read returned 0 length bytes' % ( len(buf), foo ))
by
'read returned 0 length bytes' % ( len(buf), rlen ))

What steps will reproduce the problem?
1.  run: memcached -d -c 64 -vv -s mem.socket
2.
3.

What is the expected output? What do you see instead?
I expect the daemon to run as normal.

I see a bind(): Permission Denied error.  Could this be caused by the socket 
file permissions?


What version of the product are you using? On what operating system?
memcached 1.4.9  on an unknown Linux OS (my host...)

Please provide any additional information below.

1)
The textual delete command w/expire time in the binary protocol version:
It's now possible to add and replace an item inside the expiry time window
that was previously set when the item was deleted with an expiry time.
e.g. :
"delete foo 10\r\n" returns "DELETED\r\n"
"add foo 0 0 7\r\nfoo-add\r\n" returns "STORED\r\n" instead of "NOT_STORED\r\n"
"replace foo 0 0 11\r\nfoo-replace\r\n" returns "STORED\r\n" instead of
"NOT_STORED\r\n"

2)
The textual delete command with both expire time and noreply:
e.g.
"delete noreply:foo 10 noreply" returns "ERROR\r\n".
Two things are wrong: 1) There should be no reply. 2) Any reply should've
been either "DELETED\r\n" or "NOT_FOUND\r\n".

It should be possible to detect the number of bytes actually allocated in a
given slab class to make it easier to detect if one is using the wrong
growth factor.

Hi!

The reallocation size in grow_stats_buf() in memcached.c is incorrect, thus 
causes a 
segmentation fault when we encounter a large stats output (e.g. when the daemon 
has over 40 
slab classes).

We only reallocate the number of bytes that will accommodate the "needed" size 
plus a little 
more from doubling the nsize variable. The problem is that we realloc() based 
on this size. What 
we need to do is add the offset size to guarantee enough size: 

  realloc(c->stats.buffer, nsize + c->stats.offset);

Here's the patch on github:

http://github.com/tmaesaka/memcached/commit/404fd37417a6758d468d8c9f70e4c643c2b8
9
051

Cheers,
Toru

Currently we have two cache allocators:
   * connection structures
   * suffix usage

Currently both of them use a shared pool of resources from all threads, and
we might want to make them thread local. We don't need two implementations
of the same functionality, so we should refactor the code.

I have pushed a proposal for a cache allocator (compatible with libumem if
you have that) on github:

http://github.com/trondn/memcached/tree/cache_alloc