a low-frequency get may got wrong item about memcached

[GoogleCodeExporter]

I try to understand the process, tell me if i misunderstood:
1. a "get" operation hit: 
https://github.com/memcached/memcached/blob/1.4.22/memcached.c#L2961 , the 
state is it->refcount > 1 and it->time is not updated.
2. at the same time, a "set" operation is going and hit 
https://github.com/memcached/memcached/blob/1.4.22/items.c#L150, the "search" 
item happens to be the "get" item.
3. the "search" item's refcount force to be 1 and free by slabs_free!
4. the "set" operation then call slabs_alloc and get the same item.
5. the "set" operation update(overlayed) the item.
6. the "get" operation response the overlayed item to requester.

Original comment by [email protected] on 28 Mar 2015 at 2:28

[GoogleCodeExporter]

That is the bug with tail_repair_time, and is why we turned it off by default 
in newer versions. It's only supposed to exist to work around a legitimate 
refcount leak, which we haven't had in a while.

Do you have this bug outside of tail_repair_time?

Original comment by [email protected] on 28 Mar 2015 at 5:36

[GoogleCodeExporter]

No, thanks for your reply.

Original comment by [email protected] on 29 Mar 2015 at 3:11

[GoogleCodeExporter]

ok, closing this.

Original comment by [email protected] on 29 Mar 2015 at 4:44

• Changed state: Invalid

[GoogleCodeExporter]

The help tips say that tail_repair_time is default to be 3 hours, it may need 
to be fixed, and maybe add a warning.

[10:43:34]~/prog/memcached-1.4.22 $ ./memcached -h | grep -A 2 
'tail_repair_time'
              - tail_repair_time: Time in seconds that indicates how long to wait before
                forcefully taking over the LRU tail item whose refcount has leaked.
                The default is 3 hours.

Original comment by [email protected] on 30 Mar 2015 at 2:49