![]() ``` $ CC=clang CXX=clang++ cmake ../../ -DCMAKE_BUILD_TYPE=Debug -DMI_DEBUG_UBSAN=on $ make $ ./mimalloc-test-api test: malloc-zero... ok. test: malloc-nomem1... mimalloc: error: allocation request is too large (9223372036854775808 bytes) mimalloc: error: allocation request is too large (9223372036854775808 bytes) mimalloc: error: unable to allocate memory (9223372036854775808 bytes) ok. test: malloc-null... ok. test: malloc-large... .../src/segment.c:750:23: runtime error: index 1089 out of bounds for type 'mi_slice_t [1024]' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior .../src/segment.c:750:23 in ``` See: https://github.com/microsoft/mimalloc/issues/543 Signed-off-by: Christian Heimes <christian@python.org> |
||
---|---|---|
.. | ||
CMakeLists.txt | ||
main-override-static.c | ||
main-override.c | ||
main-override.cpp | ||
main.c | ||
readme.md | ||
test-api.c | ||
test-stress.c |
Testing allocators is difficult as bugs may only surface after particular
allocation patterns. The main approach to testing mimalloc is therefore
to have extensive internal invariant checking (see page_is_valid
in page.c
for example), which is enabled in debug mode with -DMI_DEBUG_FULL=ON
.
The main testing strategy is then to run mimalloc-bench
using full
invariant checking to catch any potential problems over a wide range of intensive
allocation benchmarks and programs.
However, this does not test well for the entire API surface and this is tested
with test-api.c
when using make test
(from out/debug
etc). (This is
not complete yet, please add to it.)
The main.c
and main-override.c
are there to test if building and overriding
from a local install works and therefore these build a separate test/CMakeLists.txt
.