mirror of
https://github.com/git-for-windows/git.git
synced 2026-05-31 21:40:27 -05:00
1350d79fe1
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, in8db127d43f(reftable: avoid leaks on realloc error, 2024-12-28) and in2cca185e85(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 <johannes.schindelin@gmx.de>