-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
uint32_t overflow cause busy loop in 1.0.18 #62
Comments
|
|
memcached_server_response_count(ptr) returns 0 when ptr is NULL or ptr->cursor_active is NULL. Decrementing this and assigning to a uint32_t produces 2^32-1, so the error check if (no_msg > 0) only fails if ptr->cursor_active == 1. I suspect the right answer is to not use uint32_t here (before it was uint32_t it was int; not sure why it was converted to unsigned) and instead use int32_t. That change is here: For what it's worth, I've seen this bug tickled when calling set with a key containing a newline (\n) from PHP 5.5's Memcached class. The Memcached server doesn't like that (seems to be interpreting the second line as a new command) and errors out -- eventually triggering this loop as it attempts to unwind from the error. |
The same in here, PHP just crashes. Bt:
|
This PR probably fixes the issue: |
Just to be clear, "This PR probably fixes the issue" in the previous comment refers to the fact that the Memcached-libmemcached repo contains a copy of the libmemcached code. It's the changes in that PR that need to be applied here to the upstream libmemcached code. So "This PR probably fixes the issue" -> "The changes in this PR probably fix the issue if we applied them here". There's also the patch provided by "bin (0x3fffffff)" in the first comment on this issue. I've not applied the PR to Memcached-libmemcached yet because I'm waiting on some acknowledgement from the libmemcached team of which fix is likely to be applied here. Any news? |
is there anyone to fix this in next release? |
Imported from Launchpad using lp2gh.
We are using libmemcached 1.0.18 and observed occasionally very high CPU consumption.
After some debugging, the cause is located in libmemcached/purge.cc :
During debugging, we found that memcached_server_response_count(ptr) sometimes return a large value which equals to (uint32_t)(0-1) .
In order to fix this issue, we took an quick & dirty solution, which refuses to decrement by 1 when 0. This patch is attached below.
But still, I haven't found the root cause, and I'm afraid the root cause would leads to more possible hidden issues. So hope someone else could catch and fix this bug.
The text was updated successfully, but these errors were encountered: