1. 21 Oct, 2018 2 commits
    • buf::oom tests: use custom allocator for oom failures · 2e34efaa
      Create a custom allocator for the `buf::oom` tests that will fail with
      out-of-memory errors in predictable ways.  We were previously trying to
      guess the way that various allocators on various platforms would fail
      in a way such that `malloc`/`realloc` would return `NULL` (instead of
      aborting the application, or appearing suspicious to various
      instrumentation or static code analysis tools like valgrind.)
      
      Introduce a fake `malloc` and `realloc` that will return `NULL` on
      allocations requesting more than 100 bytes.  Otherwise, we proxy to the
      default allocator.  (It's important to use the _default_ allocator, not
      just call `malloc`, since the default allocator on Windows CI builds may
      be the debugging C runtime allocators which would not be compatible with
      a standard `malloc`.)
      Edward Thomson committed
    • tests: don't run buf::oom on 32-bit systems · 415a8ae9
      On a 32-bit Linux systems, the value large enough to make malloc
      guarantee a failure is also large enough that valgrind considers it
      "fishy".  Skip this test on those systems entirely.
      Edward Thomson committed
  2. 26 Jul, 2018 1 commit
    • buf tests: allocate a smaller size for the oom · 219512e7
      On Linux (where we run valgrind) allocate a smaller buffer, but still an
      insanely large size.  This will cause malloc to fail but will not cause
      valgrind to report a likely error with a negative-sized malloc.
      
      Keep the original buffer size on non-Linux platforms: this is
      well-tested on them and changing it may be problematic.  On macOS, for
      example, using the new size causes `malloc` to print a warning to
      stderr.
      Edward Thomson committed
  3. 10 Jun, 2018 1 commit
  4. 19 Mar, 2018 1 commit
  5. 26 May, 2016 3 commits
  6. 13 Feb, 2015 2 commits
  7. 09 Jan, 2015 1 commit
  8. 14 Nov, 2013 1 commit