You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
t-reftable-basics: stop assuming that malloc is not a constant
As indicated by the `#undef malloc` line in `reftable/basics.h`, it is
quite common to compile in allocators other than the default one by
defining `malloc` constants and friends.
This pattern is used e.g. in Git for Windows, which uses the powerful
and performant `mimalloc` allocator.
Furthermore, in `reftable/basics.c` this `#undef malloc` is
_specifically_ disabled by virtue of defining the
`REFTABLE_ALLOW_BANNED_ALLOCATORS` constant before including
`reftable/basic.h`.
However, in 8db127d (reftable: avoid leaks on realloc error,
2024-12-28) and in 2cca185 (reftable: fix allocation count on
realloc error, 2024-12-28), `reftable_set_alloc()` function calls were
introduced that pass `malloc`, `realloc` and `free` function pointers as
parameters _after_ `reftable/basics.h` ensured that they were no longer
`#define`d.
This causes problems because those calls happen after the initial
allocator has already been used to initialize an array, which is
subsequently resized using the overridden default `realloc()` allocator.
You cannot mix and match allocators like that, which leads to a
`STATUS_HEAP_CORRUPTION` (C0000374), and when running this unit test
through shell and/or `prove` (which only support 7-bit status codes), it
surfaces as exit code 127.
It is totally unnecessary to pass those function pointers to
`malloc`/`realloc`/`free` in, though: The `reftable` code goes out of
its way to fall back to the initial allocator when passing `NULL`
parameters instead. So let's do that instead of causing heap
corruptions.
Signed-off-by: Johannes Schindelin <[email protected]>
0 commit comments