Incorrect MAX_NUMBER_OF_SLAB_CLASSES results in crash for memcached > 1.4.23
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Moodle |
New
|
Undecided
|
Unassigned | ||
| libmemcached |
In Progress
|
High
|
Brian Aker | ||
| php-memcached |
Fix Released
|
Unknown
|
|||
Bug Description
We recently upgraded our memcached server from 1.4.22 to 1.4.25 With this upgrade our homemade script that displays a (sorted) output of all memcache keys did no longer work. If relevant: it is a PHP script using the following call https:/
Some info:
libmemcached 1.0.4
memcached 1.4.25
php 5.6.17
centos 5
We debugged the issue and found that the "MAX_NUMBER_
So, what goes wrong:
In the file dump.cc (https:/
on line 50 is defined that there are 200 slab classes
However this is no longer the case:
In this commit https:/
So when memcached_dump is executed the memcached server will return an error (Illegal slab ID if I'm not mistaking) and this will output the error:
"libmemcached/
Please not that in this commit https:/
So:
It seems that fetching more slabs than there are available is not a good idea :)
To me it seems there are some solutions:
- Simply change the MAX_NUMBER_
- Detect the (specific) error and return everything already fetched
How to reproduce:
- Use libmemcached 1.0.4 (or newer, as far as I can see it is an issue)
- Use memcached 1.4.23 or newer
- Execute the 'memcached_dump' call and see that it fails
- And/Or telnet to ip.of.memcached
If more info is needed please let me know.
Related branches
- Tangent Trunk: Pending requested
-
Diff: 17 lines (+2/-1)1 file modifiedconfigure.ac (+2/-1)
| Andrew Nicols (dobedobedoh) wrote | #1 |
| Matthijs (matthijs-1) wrote | #2 |
| Changed in php-memcached: | |
| status: | Unknown → New |
| nadavkav (nadavkav) wrote | #3 |
| Changed in php-memcached: | |
| status: | New → Fix Released |
| Changed in libmemcached: | |
| status: | New → In Progress |
| milestone: | none → 1.0.19 |
| importance: | Undecided → High |
| assignee: | nobody → Brian Aker (brianaker) |
I'm seeing this too and it's causing a range of breakages as a result.
In our case we use getAllKeys to filter keys for a targetted purge. As a result, our cache is not purged leading to unreliable behaviour.
As an alternative to the above suggestions, calling a `stats slabs` or `stats items` command returns a list of the stats for each slab.
It should be reasonably easy to loop over the results and calls the relevant `stats cachedump %u 0 0\r\n` on just the slabs returned and would result in one single call to fetch the list of slabs, vs 63/256 calls to return a list of empty slabs.