Tracking allocator sanitizer failure with container-overflow

[alexveden]

I noticed this when I'm running my c3tools CI, it definitely triggered by Tracking allocator, and it goes away when I run tests with a new --test-noleak (it disables Tracking allocator) from PR #1988.

https://github.com/alexveden/c3tools/actions/runs/13433802141/job/37531416305

==5632==ERROR: AddressSanitizer: container-overflow on address 0x7ffed9e78820 at pc 0x7fcb1983a397 bp 0x7ffed9e783f0 sp 0x7ffed9e77b98
READ of size 144 at 0x7ffed9e78820 thread T0
    #0 0x7fcb1983a396 in __interceptor_memcpy ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
    #1 0x55a3d370c061 in std_collections_map$ulong$std.core.mem.allocator.Allocation$.HashMap.set /home/runner/work/c3tools/c3tools/c3c/lib/std/collections/hashmap.c3:238
    #2 0x55a3d3751f43 in std.core.mem.allocator.TrackingAllocator.acquire /home/runner/work/c3tools/c3tools/c3c/lib/std/core/allocators/tracking_allocator.c3:85
    #3 0x55a3d376724b in malloc_try /home/runner/work/c3tools/c3tools/c3c/lib/std/core/mem_allocator.c3:64
    #4 0x55a3d376724b in alloc_with_padding /home/runner/work/c3tools/c3tools/c3c/lib/std/core/mem_allocator.c3:236
    #5 0x55a3d376724b in std.core.dstring.DString.new_init /home/runner/work/c3tools/c3tools/c3c/lib/std/core/dstring.c3:15
    #6 0x55a3d376da30 in std.core.dstring.new_with_capacity /home/runner/work/c3tools/c3tools/c3c/lib/std/core/dstring.c3:33
    #7 0x55a3d376dc60 in std.core.dstring.new /home/runner/work/c3tools/c3tools/c3c/lib/std/core/dstring.c3:41
    #8 0x55a3d39c0a56 in test.c3tools.lsp.document.test_document_context /home/runner/work/c3tools/c3tools/test/c3tools/lsp/test_document.c3:131
    #9 0x55a3d3773f39 in std.core.runtime.run_tests /home/runner/work/c3tools/c3tools/c3c/lib/std/core/runtime_test.c3:266
    #10 0x55a3d37777a1 in std.core.runtime.default_test_runner /home/runner/work/c3tools/c3tools/c3c/lib/std/core/runtime_test.c3:320
    #11 0x55a3d3777f51 in @_main_runner /home/runner/work/c3tools/c3tools/c3c/lib/std/core/private/main_stub.c3:54
    #12 0x55a3d3777f51 in main /home/runner/work/c3tools/c3tools/c3c/lib/std/core/runtime_test.c3:317
    #13 0x7fcb19429d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f)
    #14 0x7fcb19429e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f)
    #15 0x55a3d36fc574 in _start (/home/runner/work/c3tools/c3tools/build/testrun+0x1f2574)

Address 0x7ffed9e78820 is located in stack of thread T0 at offset 480 in frame
    #0 0x55a3d370bf5f in std_collections_map$ulong$std.core.mem.allocator.Allocation$.HashMap.set /home/runner/work/c3tools/c3tools/c3c/lib/std/collections/hashmap.c3:238

  This frame has 4 object(s):
    [32, 176) ''
    [240, 248) ''
    [272, 280) ''
    [304, 336) '' <== Memory access at offset 480 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_container_overflow=0.

[lerno]

I think this might be a bug.