|
2e34efaa
|
2018-10-21T13:10:06
|
|
buf::oom tests: use custom allocator for oom failures
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`.)
|
|
|
415a8ae9
|
2018-09-13T13:27:07
|
|
tests: don't run buf::oom on 32-bit systems
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.
|
|
|
219512e7
|
2018-07-20T14:14:16
|
|
buf tests: allocate a smaller size for the oom
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.
|
|
ecf4f33a
|
2018-02-08T11:14:48
|
|
Convert usage of `git_buf_free` to new `git_buf_dispose`
|
|
4aa664ae
|
2015-02-10T23:55:07
|
|
git_buf_grow_by: increase buf asize incrementally
Introduce `git_buf_grow_by` to incrementally increase the size of a
`git_buf`, performing an overflow calculation on the growth.
|
|
4b1018d2
|
2015-01-08T17:24:12
|
|
Fix crash in free() when git_buf_grow() fails.
|