1. 22 May, 2020 23 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 6 commits
  4. 14 May, 2020 7 commits
    • antirez's avatar
      Track events processed while blocked globally. · 74249be4
      antirez authored
      Related to #7234.
      74249be4
    • antirez's avatar
      Some rework of #7234. · 8bf660af
      antirez authored
      8bf660af
    • Oran Agra's avatar
      fix redis 6.0 not freeing closed connections during loading. · 9da134cd
      Oran Agra authored
      This bug was introduced by a recent change in which readQueryFromClient
      is using freeClientAsync, and despite the fact that now
      freeClientsInAsyncFreeQueue is in beforeSleep, that's not enough since
      it's not called during loading in processEventsWhileBlocked.
      furthermore, afterSleep was called in that case but beforeSleep wasn't.
      
      This bug also caused slowness sine the level-triggered mode of epoll
      kept signaling these connections as readable causing us to keep doing
      connRead again and again for ll of these, which keep accumulating.
      
      now both before and after sleep are called, but not all of their actions
      are performed during loading, some are only reserved for the main loop.
      
      fixes issue #7215
      9da134cd
    • antirez's avatar
      Regression test for #7249. · f7f219a1
      antirez authored
      f7f219a1
    • antirez's avatar
      rax.c updated from upstream antirez/rax. · 69362958
      antirez authored
      69362958
    • antirez's avatar
      Tracking: send eviction messages when evicting entries. · e3b5648d
      antirez authored
      A fix for #7249.
      e3b5648d
    • Oran Agra's avatar
      fix unstable replication test · 5c41802d
      Oran Agra authored
      this test which has coverage for varoius flows of diskless master was
      failing randomly from time to time.
      
      the failure was:
      [err]: diskless all replicas drop during rdb pipe in tests/integration/replication.tcl
      log message of '*Diskless rdb transfer, last replica dropped, killing fork child*' not found
      
      what seemed to have happened is that the master didn't detect that all
      replicas dropped by the time the replication ended, it thought that one
      replica is still connected.
      
      now the test takes a few seconds longer but it seems stable.
      5c41802d
  5. 09 May, 2020 2 commits