1. 21 Feb, 2023 2 commits
    • Refactor swisstable iterator debug messages code. The motivations are (a)… · 7a522a57
      Refactor swisstable iterator debug messages code. The motivations are (a) distinguish between the "likely erased" and "could have rehashed" cases when generations are enabled, (b) suggest running under ASan when generations aren't enabled and doing so would narrow down the possible error cases, and (c) make ABSL_INTERNAL_ASSERT_IS_FULL not be a macro.
      
      PiperOrigin-RevId: 511255275
      Change-Id: I5a44a813cd310837d0bd0209d2187b100be201e7
      Evan Brown committed
    • absl: fix potential int overflow in ELF reading · d9ae096e
      Both e_shentsize and e_shstrndx are uint16, so the product
        elf_header.e_shentsize * elf_header.e_shstrndx
      can overflow the promoted type int (MAX_UINT16 * MAX_UINT16 > MAX_INT),
      which is undefined behavior. Not sure if it can affect any real cases
      or not, though.
      
      Cast e_shentsize to loff_t instead of e_shoff.
      This makes both multiplication and addition to use loff_t type.
      
      PiperOrigin-RevId: 511254775
      Change-Id: I39c493bfb539cca6742aae807c50718d31e7c001
      Abseil Team committed
  2. 18 Feb, 2023 2 commits
  3. 17 Feb, 2023 2 commits
    • Update latest Linux container to unbreak Kokoro · a0f9b465
      PiperOrigin-RevId: 510518832
      Change-Id: I086c8f2e34312e2b0384b3c67b9c04814d41ddf0
      Derek Mauro committed
    • Synchronization: Add support for true relative timeouts using · ed37a45a
      monotonic clocks on Linux when the implementation uses futexes
      
      After this change, when synchronization methods that wait are passed
      an absl::Duration to limit the wait time, these methods will wait for
      that interval, even if the system clock is changed (subject to any
      limitations with how CLOCK_MONOTONIC keeps track of time). In other
      words, an observer measuring the time with a stop watch will now see
      the correct interval, even if the system clock is changed. Previously,
      the duration was added to the current time, and methods would wait
      until that time was reached on the possibly changed realtime system
      clock.
      
      The behavior of the synchronization methods that take an absl::Time is
      unchanged.  These methods always wait until the absolute point in time
      is reached and respect changes to the system clock. In other words, an
      observer will always see the timeout occur when a wall clock reaches
      that time, even if the clock is manipulated externally.
      
      Note: ABSL_PREDICT_FALSE was removed from the error case in Futex as
      timeouts are handled by this case, and timeouts are part of normal
      operation.
      PiperOrigin-RevId: 510405347
      Change-Id: I0b3ea390de97014cfa353079ae2e0c1c637aca69
      Derek Mauro committed
  4. 16 Feb, 2023 3 commits
  5. 15 Feb, 2023 1 commit
  6. 14 Feb, 2023 4 commits
  7. 13 Feb, 2023 3 commits
  8. 10 Feb, 2023 2 commits
    • Workaround MSan false positive. · cde2f0ea
      On Linux Kernels >= 5.4 MSan reports a false positive when accessing thread local storage data from loaded libraries.
      
      This was reported on Chromium (which on some build configurations uses absl as a dynamic library). More info here: crbug.com/1414573.
      
      PiperOrigin-RevId: 508645053
      Change-Id: I5d5a97e1ee7230cc23f3934a4ec5594b883918b4
      Abseil Team committed
    • Rewrite KernelTimeout to support both absolute and relative timeouts · fa485540
      APIs that take KernelTimeout as a parameter can now query if an
      absolute or relative timeout was requested. If the underlying API can
      only use one type of timeout, the code will do a reasonable
      conversion.
      
      The goal is to eventually enable the possibility of using wait times
      that are based on monotonic clocks that are safe against system clock
      steps.
      
      PiperOrigin-RevId: 508541507
      Change-Id: Id08bf13515f3e1bfd78d88393cde98a6fd3ef72c
      Derek Mauro committed
  9. 09 Feb, 2023 1 commit
  10. 08 Feb, 2023 2 commits
  11. 07 Feb, 2023 1 commit
  12. 06 Feb, 2023 2 commits
  13. 04 Feb, 2023 1 commit
  14. 03 Feb, 2023 1 commit
  15. 02 Feb, 2023 3 commits
  16. 01 Feb, 2023 3 commits
  17. 31 Jan, 2023 1 commit
  18. 30 Jan, 2023 1 commit
  19. 28 Jan, 2023 1 commit
  20. 27 Jan, 2023 3 commits
  21. 26 Jan, 2023 1 commit