|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #56915 memcache::put fail on certain strings
Submitted: 2006-03-25 18:43 UTC Modified: 2006-05-17 18:35 UTC
From: gary at isohunt dot com Assigned:
Status: Not a bug Package: memcache (PECL)
PHP Version: 4.4.1 OS: Gentoo, amd64
Private report: No CVE-ID: None
 [2006-03-25 18:43 UTC] gary at isohunt dot com
Storing the following example value would have $mc->set() return FALSE:

2D4447A819C502E02CCD7225182ACA07 N blah blah blah

What exactly triggers the failure is not certain, but a common pattern of similar failures is one of the words, separated by non alphanumeric characters, has length 32. As in the hash in first word of example above.

Reproduce code:
$mc = new Memcache;
$mc->addServer($host, 11211);
$return = $mc->set($key, $value, 0, $ttl);

where $value has pattern described above

Expected result:
$return == TRUE

Actual result:
$return == FALSE


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-03-25 23:19 UTC] mikael at synd dot info
The included code outputs "bool(true)" as expected using PHP 4.4.2 and memcache extension 2.0.1, would you mind copying the code verbatim and run it against your system. 

Problems I can imagine that might cause this would be some intermittent network problems with the $host or some weird 64-bit compat problems, if you have compiled gentoo/php/memcache for 64-bits.

$host = 'localhost';
$key = 'foo';
$value = '2D4447A819C502E02CCD7225182ACA07 N blah blah blah';
$ttl = 15;

$mc = new Memcache;
$mc->addServer($host, 11211);
$return = $mc->set($key, $value, 0, $ttl);

 [2006-03-26 19:08 UTC] robbat2 at gentoo dot org
(I work for the submitter, just helping follow up on this).
I ran your test case - it fails on amd64, but works on x86.

Our amd64 boxes are on 4.4.1-pl3-gentoo, and our 32-bit boxes are on 4.4.0-pl3-gentoo and 4.4.2-gentoo.

This suggests a 64-bit bug in PHP/pecl-memcache to me, since your usage of localhost rules out network failure, and we haven't seen any other network issues previously. (We push 200Gb+ of traffic daily leaving the network, and several times that inside the network).

Can you offer any suggestions as to debugging specific parts of pecl-memcache for 64-bit issues? I'll try to test against other 64-bit architectures.
 [2006-03-26 19:33 UTC] robbat2 at gentoo dot org
4.4.2 on amd64 also fails in the same way.
 [2006-05-16 05:25 UTC] mikael at synd dot info
Got hold of an amd64 system running RedHat but wasn't able to reproduce the problem:

[mikl@login64 ~/tmp]$ ./php-4.4.1/sapi/cli/php foo.php

cat /proc/cpuinfo
 AMD Opteron(tm) Processor 248
checking build system type... x86_64-unknown-linux-gnu
uname -a 
 Linux 2.6.9-22.0.2.ELsmp #1 SMP Thu Jan 5 17:11:56 EST 2006 x86_64 x86_64 x86_64 GNU/Linux

Would you mind attaching a bit more info such as an strace session illustrating the problem and configure/make output,  and any other info you think might help, and hopefully we'll be able to solve the problem.

 [2006-05-17 10:04 UTC] tony2001 at phpclub dot net
Please try the latest release.
I managed to catch and fix a problem which looks pretty much the same, but it appeared only when using compression.
 [2006-05-17 18:29 UTC] gary at isohunt dot com
It turns out this is a memcached the server's problem with OUT OF MEMORY when it shouldn't:

Thanks for the help.
 [2006-05-17 18:35 UTC] tony2001 at phpclub dot net
Ok, thanks for the clarification.
 [2006-05-17 18:48 UTC] robbat2 at gentoo dot org
Ok, this has turned out to actually be an obscure memcached bug with regards to slab allocation.

It's supposed to be fixed in 1.1.13pre, so we'll test that out soon.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Mon Oct 03 08:05:54 2022 UTC