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 |
Undecided
|
Unassigned | ||
| 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 2016-02-03
- Diff: 0 lines
Andrew Nicols (dobedobedoh) wrote : | #1 |
Matthijs (matthijs-1) wrote : | #2 |
Hi Andrew, yes that is sort of the same usecase we have. And yes this problem is still not fixed (as you can see I never even got a reply). So unfortunately for now we'll stick to version 1.4.22
I'm still not sure if there is an "get slabs amount" call but your solution should work :)
Hoping the devs can at least reply to this issue!
Changed in php-memcached: | |
status: | Unknown → New |
nadavkav (nadavkav) wrote : | #3 |
I can confirm we are also experiencing this major issue in our servers.
Changed in php-memcached: | |
status: | New → Fix Released |
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.