Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


SERIALIZER_IGBINARY can cause issues with incr/decr #254

dgsan opened this Issue · 4 comments

3 participants


From phpredis:
$redis->set('bongo', 8);

From redis-cli: // I mean redis-cli... oops. (really late update 12-31-2012.)
get bongo

From phpredis:
$q = $redis->incr('bongo');
echo $q;
// 1 // Expecting: 9

From redis-cli:
get bongo

Expect: that you can set bongo to 8, call incr, get 9.

Most of the time the strings like "\x00\x00\x00\x02\x06\b" get treated as 0 when you call incr/decr, but once in a while they seem to trigger a segfault/core dump if you call get on them.

For example, I recently wound up with the value "\x00\x00\x00\x02\nP`\x97Q" (probably improperly formatted somehow), which causes get() of the key with that value to seg fault/core dump.

I'm kind of inclined to think that a mode where numeric values, or at least integer values, aren't serialized, but other types are, may be a good idea, as I'm not sure decr/incr could be made to work with serialized integers as they are atomic and thus probably assume/require redis's normal internal representation.

As it stands, working around this is presenting some challenges.

I'm checked out at commit 7dfac44.


My workaround is ending up much like various previous commenter's -- wrap the redis object in such a way that if(is_numeric) on set just store, if(is_numeric) on get just return, else use json encode,decode or some such (considering php serialize as not that portable).



Check out the new branch json. Clone it like so:
git clone -b json

It's really experimental right now, as we'll have to figure out (a) if we want to incorporate JSON into the main branch, and (b) how to handle the whole associative array vs. stdClass decode option.


This also reproducible, with SERIALIZER_PHP



I don't really think this is a bug. The purpose of the serializer is to allow the client to store whatever they want (arrays, objects, etc) in Redis in a transparent way. There is a non trivial amount of overhead in guessing if a value doesn't actually need to be serialized, and then more in determining if the value is just raw or has some sort of serialization error.

My suggestion would be to control this on the client side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.