1. 22 May, 2020 14 commits
  2. 16 May, 2020 2 commits
    • antirez's avatar
      Redis 6.0.3. · 7803b114
      antirez authored
      7803b114
    • antirez's avatar
      Remove the client from CLOSE_ASAP list before caching the master. · 1eab62f7
      antirez authored
      This was broken in 1a7cd2c0: we identified a crash in the CI, what
      was happening before the fix should be like that:
      
      1. The client gets in the async free list.
      2. However freeClient() gets called again against the same client
         which is a master.
      3. The client arrived in freeClient() with the CLOSE_ASAP flag set.
      4. The master gets cached, but NOT removed from the CLOSE_ASAP linked
         list.
      5. The master client that was cached was immediately removed since it
         was still in the list.
      6. Redis accessed a freed cached master.
      
      This is how the crash looked like:
      
      === REDIS BUG REPORT START: Cut & paste starting from here ===
      1092:S 16 May 2020 11:44:09.731 # Redis 999.999.999 crashed by signal: 11
      1092:S 16 May 2020 11:44:09.731 # Crashed running the instruction at: 0x447e18
      1092:S 16 May 2020 11:44:09.731 # Accessing address: 0xffffffffffffffff
      1092:S 16 May 2020 11:44:09.731 # Failed assertion:  (:0)
      
      ------ STACK TRACE ------
      EIP:
      src/redis-server 127.0.0.1:21300(readQueryFromClient+0x48)[0x447e18]
      
      And the 0xffff address access likely comes from accessing an SDS that is
      set to NULL (we go -1 offset to read the header).
      1eab62f7
  3. 15 May, 2020 5 commits
  4. 14 May, 2020 5 commits
  5. 09 May, 2020 4 commits
    • ShooterIT's avatar
      a23cdbb9
    • antirez's avatar
      Cluster: clarify we always resolve the sender. · 1276058e
      antirez authored
      1276058e
    • antirez's avatar
      Cluster: refactor ping/data delay handling. · 002fcde3
      antirez authored
      002fcde3
    • antirez's avatar
      Cluster: introduce data_received field. · 960186a7
      antirez authored
      We want to send pings and pongs at specific intervals, since our packets
      also contain information about the configuration of the cluster and are
      used for gossip. However since our cluster bus is used in a mixed way
      for data (such as Pub/Sub or modules cluster messages) and metadata,
      sometimes a very busy channel may delay the reception of pong packets.
      So after discussing it in #7216, this commit introduces a new field that
      is not exposed in the cluster, is only an internal information about
      the last time we received any data from a given node: we use this field
      in order to avoid detecting failures, claiming data reception of new
      data from the node is a proof of liveness.
      960186a7
  6. 08 May, 2020 10 commits