1. 20 Mar, 2024 1 commit
  2. 03 Oct, 2023 1 commit
    • Madelyn Olson's avatar
      Better standardize around assertions (#12539) · 31c3172d
      Madelyn Olson authored
      We use the C standard assert() in various places in the codebase, which requires NDEBUG to be undefined. We introduced the redisassert.h file in order to allow low level files to access the assert that maps to serverPanic, but this was only applied tactically and is not available broadly.
      
      This PR removes all usage of the standard library asserts and replaces them with an assert that maps to serverPanic. It makes us immune to accidentally setting the NDEBUG flag preventing assertions. I also marked marked the server asserts as "likely" to not execute. I spot checked various points in the code, and it didn't change the code layout on my x86 mac, but it is more consistent with redisassert.h and seems more correct overall.
      31c3172d
  3. 11 Nov, 2021 1 commit
    • Ozan Tezcan's avatar
      Add sanitizer support and clean up sanitizer findings (#9601) · b91d8b28
      Ozan Tezcan authored
      - Added sanitizer support. `address`, `undefined` and `thread` sanitizers are available.  
      - To build Redis with desired sanitizer : `make SANITIZER=undefined`
      - There were some sanitizer findings, cleaned up codebase
      - Added tests with address and undefined behavior sanitizers to daily CI.
      - Added tests with address sanitizer to the per-PR CI (smoke out mem leaks sooner).
      
      Basically, there are three types of issues : 
      
      **1- Unaligned load/store** : Most probably, this issue may cause a crash on a platform that
      does not support unaligned access. Redis does unaligned access only on supported platforms.
      
      **2- Signed integer overflow.** Although, signed overflow issue can be problematic time to time
      and change how compiler generates code, current findings mostly about signed shift or simple
      addition overflow. For most platforms Redis can be compiled for, this wouldn't cause any issue
      as far as I can tell (checked generated code on godbolt.org).
      
       **3 -Minor leak** (redis-cli), **use-after-free**(just before calling exit());
      
      UB means nothing guaranteed and risky to reason about program behavior but I don't think any
      of the fixes here worth backporting. As sanitizers are now part of the CI, preventing new issues
      will be the real benefit. 
      b91d8b28
  4. 03 May, 2021 1 commit
  5. 29 Sep, 2020 1 commit
  6. 16 Dec, 2015 2 commits
    • antirez's avatar
      Hopefully better memory test on crash. · a1c9c05e
      antirez authored
      The old test, designed to do a transformation on the bits that was
      invertible, in order to avoid touching the original memory content, was
      not effective as it was redis-server --test-memory. The former often
      reported OK while the latter was able to spot the error.
      
      So the test was substituted with one that may perform better, however
      the new one must backup the memory tested, so it tests memory in small
      pieces. This limits the effectiveness because of the CPU caches. However
      some attempt is made in order to trash the CPU cache between the fill
      and the check stages, but not for the addressing test unfortunately.
      
      We'll see if this test will be able to find errors where the old failed.
      a1c9c05e
    • antirez's avatar
      ac8f4a6a
  7. 09 Dec, 2014 1 commit
  8. 01 Dec, 2014 1 commit
  9. 08 Aug, 2014 1 commit
  10. 21 Jan, 2013 1 commit
  11. 29 Nov, 2012 1 commit
    • antirez's avatar
      On crash memory test rewrote so that it actaully works. · b1b602a9
      antirez authored
      1) We no longer test location by location, otherwise the CPU write cache
      completely makes our business useless.
      2) We still need a memory test that operates in steps from the first to
      the last location in order to never hit the cache, but that is still
      able to retain the memory content.
      
      This was tested using a Linux box containing a bad memory module with a
      zingle bit error (always zero).
      
      So the final solution does has an error propagation step that is:
      
      1) Invert bits at every location.
      2) Swap adiacent locations.
      3) Swap adiacent locations again.
      4) Invert bits at every location.
      5) Swap adiacent locations.
      6) Swap adiacent locations again.
      
      Before and after these steps, and after step 4, a CRC64 checksum is computed.
      If the three CRC64 checksums don't match, a memory error was detected.
      b1b602a9
  12. 21 Nov, 2012 1 commit
  13. 08 Nov, 2012 1 commit
  14. 27 Apr, 2012 1 commit
  15. 12 Apr, 2012 1 commit
  16. 11 Apr, 2012 1 commit
  17. 19 Mar, 2012 1 commit
  18. 18 Mar, 2012 3 commits
  19. 16 Mar, 2012 2 commits