Reported by mkaito, crash happened in Magnetar.
The crash: Havok.dll+0x524e63 is decl (%rcx) immediately after a compare + conditional destructor call — the hkReferencedObject::removeReference pattern (if (--refCount == 0) destroy). A Havok worker thread decremented a refcount inside an object whose backing page was no longer mapped (write fault, page not present, address in mmap territory). Textbook use-after-free of a refcounted physics object.
Why it's fatal on Linux but silent on Windows: Havok.dll's entire heap goes through MSVCR120 imports (malloc/free/_aligned_malloc — confirmed from its import table; it imports no VirtualAlloc). The wrapper shims those straight to glibc malloc. glibc serves chunks ≥ M_MMAP_THRESHOLD (~128KB+) as dedicated mmaps and munmaps them immediately on free. The Windows CRT heap essentially never returns freed pages to the OS promptly — freed memory stays mapped, so this latent Havok/Keen race (worker releasing a reference after the owning pool was freed) reads/writes stale-but-mapped garbage on Windows and nobody notices. On Linux the same race hits an unmapped page and the process dies.
Full data dump (requires NAS access for privacy): https://nas.ferenczi.eu/f/4188720
Reported by
mkaito, crash happened in Magnetar.The crash: Havok.dll+0x524e63 is decl (%rcx) immediately after a compare + conditional destructor call — the hkReferencedObject::removeReference pattern (if (--refCount == 0) destroy). A Havok worker thread decremented a refcount inside an object whose backing page was no longer mapped (write fault, page not present, address in mmap territory). Textbook use-after-free of a refcounted physics object.
Why it's fatal on Linux but silent on Windows: Havok.dll's entire heap goes through MSVCR120 imports (malloc/free/_aligned_malloc — confirmed from its import table; it imports no VirtualAlloc). The wrapper shims those straight to glibc malloc. glibc serves chunks ≥ M_MMAP_THRESHOLD (~128KB+) as dedicated mmaps and munmaps them immediately on free. The Windows CRT heap essentially never returns freed pages to the OS promptly — freed memory stays mapped, so this latent Havok/Keen race (worker releasing a reference after the owning pool was freed) reads/writes stale-but-mapped garbage on Windows and nobody notices. On Linux the same race hits an unmapped page and the process dies.
Full data dump (requires NAS access for privacy): https://nas.ferenczi.eu/f/4188720