CI / test (arm64, -DCMAKE_BUILD_TYPE=Debug -DMSAN_TOOLCHAIN_PATH=/opt/msan, 22, https://minio.weaselab.dev/public/aarch64/msan-toolchain-22.1.8.tar.zst, debug-arm64, ubuntu-latest-arm64) (pull_request) Successful in 4m26s
CI / test (amd64, -DCMAKE_BUILD_TYPE=Debug -DMSAN_TOOLCHAIN_PATH=/opt/msan, 21, https://minio.weaselab.dev/public/x86_64/msan-toolchain-21.1.8.tar.zst, debug, ubuntu-latest-amd64) (pull_request) Successful in 4m3s
The testing-only cross-check in `internal_addWrites` and
`internal_setOldestVersion` compares `impl->totalBytes`, which only accounts for
the allocations made during one instance's own API calls, against `mallocBytes`,
which is process-wide. The two are only equal while a single ConflictSet uses
`safe_malloc`, so a SHOW_MEMORY build aborts on perfectly valid programs that
keep two instances alive (the repo's own script tests do exactly that).
Keeping several ConflictSets alive is supported and does not need the
instrumentation fixed for it, so just say so where the invariant lives: on the
process-wide counters in `Internal.h`, and at each of the four cross-checks in
ConflictSet.cpp and SkipList.cpp. ShowMemoryTest.cpp's header comment and the
CMakeLists comment for the test target now point at that explanation instead of
stating the restriction without a reason.
Closes#97
weaselbot