- 22 Jan, 2015 2 commits
- 21 Jan, 2015 9 commits
-
-
antirez authored
On Darwin /dev/urandom depletes terribly fast. This is not an issue normally, but with Redis Cluster we generate a lot of unique IDs, for example during nodes handshakes. Our IDs need just to be unique without other strong crypto requirements, so this commit turns the function into something that gets a 20 bytes seed from /dev/urandom, and produces the rest of the output just using SHA1 in counter mode.
-
Matt Stancliff authored
Fixes valgrind error: 48 bytes in 1 blocks are definitely lost in loss record 196 of 373 at 0x4910D3: je_malloc (jemalloc.c:944) by 0x42807D: zmalloc (zmalloc.c:125) by 0x41FA0D: dictGetIterator (dict.c:543) by 0x41FA48: dictGetSafeIterator (dict.c:555) by 0x459B73: clusterHandleSlaveMigration (cluster.c:2776) by 0x45BF27: clusterCron (cluster.c:3123) by 0x423344: serverCron (redis.c:1239) by 0x41D6CD: aeProcessEvents (ae.c:311) by 0x41D8EA: aeMain (ae.c:455) by 0x41A84B: main (redis.c:3832)
-
Matt Stancliff authored
If array has N elements, we can't read +1 if we are already at N. Also, we need to move elements by their storage size in the array, not just by individual bytes.
-
Matt Stancliff authored
[maybe] Fixes valgrind errors: 32 bytes in 4 blocks are definitely lost in loss record 107 of 228 at 0x80EA447: je_malloc (jemalloc.c:944) by 0x806E59C: zrealloc (zmalloc.c:125) by 0x80A9AFC: clusterSetMaster (cluster.c:801) by 0x80AEDC9: clusterCommand (cluster.c:3994) by 0x80682A5: call (redis.c:2049) by 0x8068A20: processCommand (redis.c:2309) by 0x8076497: processInputBuffer (networking.c:1143) by 0x8073BAF: readQueryFromClient (networking.c:1208) by 0x8060E98: aeProcessEvents (ae.c:412) by 0x806123B: aeMain (ae.c:455) by 0x806C3DB: main (redis.c:3832) 64 bytes in 8 blocks are definitely lost in loss record 143 of 228 at 0x80EA447: je_malloc (jemalloc.c:944) by 0x806E59C: zrealloc (zmalloc.c:125) by 0x80AAB40: clusterProcessPacket (cluster.c:801) by 0x80A847F: clusterReadHandler (cluster.c:1975) by 0x30000FF: ??? 80 bytes in 10 blocks are definitely lost in loss record 148 of 228 at 0x80EA447: je_malloc (jemalloc.c:944) by 0x806E59C: zrealloc (zmalloc.c:125) by 0x80AAB40: clusterProcessPacket (cluster.c:801) by 0x80A847F: clusterReadHandler (cluster.c:1975) by 0x2FFFFFF: ???
-
Matt Stancliff authored
Fixes valgrind error: Syscall param write(buf) points to uninitialised byte(s) at 0x514C35D: ??? (syscall-template.S:81) by 0x456B81: clusterWriteHandler (cluster.c:1907) by 0x41D596: aeProcessEvents (ae.c:416) by 0x41D8EA: aeMain (ae.c:455) by 0x41A84B: main (redis.c:3832) Address 0x5f268e2 is 2,274 bytes inside a block of size 8,192 alloc'd at 0x4932D1: je_realloc (jemalloc.c:1297) by 0x428185: zrealloc (zmalloc.c:162) by 0x4269E0: sdsMakeRoomFor.part.0 (sds.c:142) by 0x426CD7: sdscatlen (sds.c:251) by 0x4579E7: clusterSendMessage (cluster.c:1995) by 0x45805A: clusterSendPing (cluster.c:2140) by 0x45BB03: clusterCron (cluster.c:2944) by 0x423344: serverCron (redis.c:1239) by 0x41D6CD: aeProcessEvents (ae.c:311) by 0x41D8EA: aeMain (ae.c:455) by 0x41A84B: main (redis.c:3832) Uninitialised value was created by a stack allocation at 0x457810: nodeUpdateAddressIfNeeded (cluster.c:1236)
-
antirez authored
The cleanup code expects that if 'di' is not NULL, it is a valid iterator that should be freed. The result of this bug was a crash of the AOF rewriting process if an error occurred after the DBs data are written and the iterator is no longer valid.
-
antirez authored
-
antirez authored
Related to issue #2289.
-
antirez authored
-
- 20 Jan, 2015 3 commits
-
-
antirez authored
Rationale is that when re-entering, it is likely due to Lua debugging hooks. Returning an error will be ignored in most cases, going totally unnoticed. With the log at least we leave a trace. Related to issue #2302.
-
antirez authored
Instead of calling redisPanic() to abort the server. Related to issue #2302.
-
antirez authored
Related to issue #2302.
-
- 13 Jan, 2015 3 commits
-
-
antirez authored
In order to avoid that misconfigured cluster nodes at some time may force an IP update on other nodes, it is required that nodes update their own address only on MEET messages. However it does not make sense to do this the first time a node is contacted and yet does not have an IP, we just risk that myself->ip remains not assigned if there are messages lost or cluster creation procedures that don't make sure everybody is targeted by at least one incoming MEET message. Also fix the logging of the IP switch avoiding the :-1 tail.
-
antirez authored
Also explicitly set version to 0, add a protocol version define, improve comments in the gossip structure. Note that the structure layout is the same after the change, we are just making the padding explicit with an additional not used 16 bits field. So this commit is still able to talk with the previous versions of cluster nodes.
-
antirez authored
Valgrind checks that the buffers we transfer via syscalls are all composed of bytes actually initialized. This is useful, it makes we able to avoid leaking informations in non initialized parts fo messages transferred to other hosts. This commit fixes one of such issues.
-
- 12 Jan, 2015 3 commits
- 09 Jan, 2015 7 commits
-
-
Matt Stancliff authored
-
Matt Stancliff authored
Adds configuration option 'supervised [no | upstart | systemd | auto]' Also removed 'bzero' from the previous implementation because it's 2015. (We could actually statically initialize those structs, but clang throws an invalid warning when we try, so it looks bad even though it isn't bad.) Fixes #2264
-
Matt Stancliff authored
We want pidfile to be NULL on startup so we can detect if the user set an explicit value versus only using the default value. Closes #1967 Fixes #2076
-
rebx authored
Previously, Redis only wrote the pid file if it was daemonizing, but many times it's useful to have the pid written out even if you're in the foreground. Some background for this is: I usually run redis via daemontools. That entails running redis-server on the foreground. Given that, I'd also want redis-server to create a pidfile so other processes (e.g. nagios) can run checks for that. Closes #463
-
antirez authored
This fix is from @NanXiao, however I was not able to retain authorship because the Pull Request original repository was removed.
-
antirez authored
-
antirez authored
Before this commit scripts were able to access / create keys outside the set of hash slots served by the local node.
-
- 08 Jan, 2015 10 commits
-
-
Matt Stancliff authored
-
Matt Stancliff authored
Under certain conditions the node list wasn't being fully populated and 'create' would fail trying to call methods on nil objects.
-
antirez authored
Thx to @badboy.
-
antirez authored
-
antirez authored
This commit introduces a new RDB data type called 'aux'. It is used in order to insert inside an RDB file key-value pairs that may serve different needs, without breaking backward compatibility when new informations are embedded inside an RDB file. The contract between Redis versions is to ignore unknown aux fields when encountered. Aux fields can be used in order to: 1. Augment the RDB file with info like version of Redis that created the RDB file, creation time, used memory while the RDB was created, and so forth. 2. Add state about Redis inside the RDB file that we need to reload later: replication offset, previos master run ID, in order to improve failovers safety and allow partial resynchronization after a slave restart. 3. Anything that we may want to add to RDB files without breaking the ability of past versions of Redis to load the file.
-
antirez authored
-
antirez authored
The new opcode is an hint about the size of the dataset (keys and number of expires) we are going to load for a given Redis database inside the RDB file. Since hash tables are resized accordingly ASAP, useless rehashing is avoided, speeding up load times significantly, in the order of ~ 20% or more for larger data sets. Related issue: #1719
-
antirez authored
-
antirez authored
Before we needed to create a string object with an embedded SDS, adn basically duplicate the SDS part into a plain zmalloc() allocation.
-
antirez authored
-
- 02 Jan, 2015 3 commits
-
-
Matt Stancliff authored
This is lzf_c and lzf_d from http://dist.schmorp.de/liblzf/liblzf-3.6.tar.gz
-
Matt Stancliff authored
This also defines REDIS_STATIC='' for building everything inside src/ and everything inside deps/lua/.
-
Matt Stancliff authored
Adds: ql_compressed (boolean, 1 if compression enabled for list, 0 otherwise) Adds: ql_uncompressed_size (actual uncompressed size of all quicklistNodes) Adds: ql_ziplist_max (quicklist max ziplist fill factor) Compression ratio of the list is then ql_uncompressed_size / serializedlength We report ql_uncompressed_size for all quicklists because serializedlength is a _compressed_ representation anyway. Sample output from a large list: 127.0.0.1:6379> llen abc (integer) 38370061 127.0.0.1:6379> debug object abc Value at:0x7ff97b51d140 refcount:1 encoding:quicklist serializedlength:19878335 lru:9718164 lru_seconds_idle:5 ql_nodes:21945 ql_avg_node:1748.46 ql_ziplist_max:-2 ql_compressed:0 ql_uncompressed_size:1643187761 (1.36s) The 1.36s result time is because rdbSavedObjectLen() is serializing the object, not because of any new stats reporting. If we run DEBUG OBJECT on a compressed list, DEBUG OBJECT takes almost *zero* time because rdbSavedObjectLen() reuses already-compressed ziplists: 127.0.0.1:6379> debug object abc Value at:0x7fe5c5800040 refcount:1 encoding:quicklist serializedlength:19878335 lru:9718109 lru_seconds_idle:5 ql_nodes:21945 ql_avg_node:1748.46 ql_ziplist_max:-2 ql_compressed:1 ql_uncompressed_size:1643187761
-