1. 22 Jan, 2015 2 commits
  2. 21 Jan, 2015 9 commits
    • antirez's avatar
      getRandomHexChars(): use /dev/urandom just to seed. · 87301be1
      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.
      87301be1
    • Matt Stancliff's avatar
      Fix cluster migrate memory leak · 051a43e0
      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)
      051a43e0
    • Matt Stancliff's avatar
      Fix potential invalid read past end of array · 29049507
      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.
      29049507
    • Matt Stancliff's avatar
      Fix cluster reset memory leak · 30152554
      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: ???
      30152554
    • Matt Stancliff's avatar
      Fix sending uninitialized bytes · 72b8574c
      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)
      72b8574c
    • antirez's avatar
      AOF rewrite: set iterator var to NULL when freed. · 4433f5a7
      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.
      4433f5a7
    • antirez's avatar
      Cluster: node deletion cleanup / centralization. · 2601e3e4
      antirez authored
      2601e3e4
    • antirez's avatar
      Cluster: set the slaves->slaveof filed to NULL when master is freed. · 59ad6ac5
      antirez authored
      Related to issue #2289.
      59ad6ac5
    • antirez's avatar
      92cfab44
  3. 20 Jan, 2015 3 commits
  4. 13 Jan, 2015 3 commits
    • antirez's avatar
      Cluster: fetch my IP even if msg is not MEET for the first time. · cf76af6b
      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.
      cf76af6b
    • antirez's avatar
      Cluster: clusterMsgDataGossip structure, explict padding + minor stuff. · 5b0f4a83
      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.
      5b0f4a83
    • antirez's avatar
      Suppress valgrind error about write sending uninitialized data. · 237ab727
      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.
      237ab727
  5. 12 Jan, 2015 3 commits
  6. 09 Jan, 2015 7 commits
  7. 08 Jan, 2015 10 commits
  8. 02 Jan, 2015 3 commits
    • Matt Stancliff's avatar
      5870e224
    • Matt Stancliff's avatar
      Set optional 'static' for Quicklist+Redis · 25e12d10
      Matt Stancliff authored
      This also defines REDIS_STATIC='' for building everything
      inside src/ and everything inside deps/lua/.
      25e12d10
    • Matt Stancliff's avatar
      Add more quicklist info to DEBUG OBJECT · 9e11d079
      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
      9e11d079