[URGENT] Unexpected memory address misalignment exception on ARM64 architecture during pointer arithmetic operation in a multi-threaded C++ environment using custom allocators

I am writing to formally request assistance regarding a non-deterministic segmentation fault that appears to originate from an unaligned memory access violation. The system is running Ubuntu 20.04 LTS on an AWS m5.large instance, which utilizes the Graviton2 ARM64 architecture — this detail is critical because we are observing behavior that differs substantially from our x86_64 development environments. Specifically, when Thread A attempts to read a 64-bit integer pointer through what it assumes is a properly aligned buffer allocated via my custom pool allocator (defined in src/allocator.hpp), the kernel reports an unaligned access exception under certain race conditions that I cannot consistently reproduce locally. Let me detail the specifics: our allocator uses std::align_val_t to align allocations at 64-byte boundaries, which is more than sufficient for ARMv8's alignment requirements of 8 bytes for doublewords. However, we have a situation where an object of type UserSession — which contains an embedded std::vector and several raw pointers — is occasionally read from memory that appears to be unaligned at the byte level despite my assertions otherwise. I suspect the culprit may be one of three things: (1) thread A might be reading through a partially constructed pointer due to a data race where Thread B has already freed or reallocated the buffer but not updated the shared index, causing Thread A to read into a different allocation boundary; (2) there could be an edge case in my pool's reuse logic where a 16-byte block is being treated as containing multiple 8-byte elements while the pointer arithmetic overshoots due to a signed/unsigned comparison error; or (3) we may be encountering the relaxed memory ordering semantics of ARMv8, where Load-Acquire

Aligned to 16 bytes instead of 8, should fix it.