0xc0000005 access violation on aarch64-pc-windows-msvc after upgrade to 0.1.49 / libmimalloc-sys 0.1.46

[GlenDC]

After upgrading from mimalloc 0.1.48 to 0.1.49 (which bumps libmimalloc-sys from 0.1.44 to 0.1.46), our CI on windows-11-arm (aarch64-pc-windows-msvc) started producing a deterministic STATUS_ACCESS_VIOLATION crash mid-test-run.

Repository (rama-cli project within that workspace): https://github.com/plabayo/rama

Symptoms

• Test binary using MiMalloc as global allocator crashes with exit code 0xc0000005
• Crash is deterministic: always the same test at the same position in the run
• The crashing test body is trivially simple: stack struct construction + a vec![...] allocation + a pure function call with no I/O or unsafe code
• Prior tests always succeed, suggesting heap corruption accumulates over prior allocations before manifesting

Reproduction

We use mimalloc as global allocator in a Rust CLI binary:

#[global_allocator]
static ALLOC: mimalloc::MiMalloc = mimalloc::MiMalloc;

Running cargo nextest run --all-features on windows-11-arm (GitHub Actions runner) reproduces consistently. Pinning back to mimalloc = "=0.1.48" / libmimalloc-sys = "0.1.44" fixes it immediately.

Environment

• OS: Windows 11 ARM (aarch64-pc-windows-msvc)
• Runner: GitHub Actions windows-11-arm
• Rust: stable
• Broken: mimalloc 0.1.49 + libmimalloc-sys 0.1.46
• Working: mimalloc 0.1.48 + libmimalloc-sys 0.1.44

Workaround

Pin the dependency in Cargo.toml:

mimalloc = { version = "=0.1.48", default-features = false }

[Havunen]

microsoft/mimalloc#1277

It is possibly fixed in 3.3.1

Can we bump mimalloc again please @octavonce

[octavonce]

Ok, I've bumped it, try now.

[Havunen]

I opened a PR to fix this issue #160 a longer story available here: microsoft/mimalloc#1277 microsoft/mimalloc#1283

[Havunen]

@octavonce This issue seems to occur when mimalloc is compiled using plain C compiler on Windows ARM platform. #160 adjusts the build process so Windows ARM also compiles using C++ compiler. When atomic.h is compiled using plain C compiler, it does write operation on readonly memory and fails to "access violation". When the program is compiled using C++ that atomic implementation is not used.

There is a PR to microsoft mimalloc to fix the atomic.h implementation, however we can workaround this by following build instructions more closely.

I asked GPT 5.4 LLM to analyze what else is different in the build process and it brought up those issues described in the PR.

[zanieb]

Just for reference, this is also affecting us downstream in uv astral-sh/uv#19189

[robrobrobrob]

This looks like microsoft/mimalloc#1277 bubbling up through libmimalloc-sys. mimalloc 3.3.0 / 3.3.1 has a broken MSVC C atomics wrapper on aarch64-pc-windows-msvc that emits non-readonly atomic loads which fault when the target page is unmapped (typically TLS / arena teardown), producing the exact 0xc0000005 you're seeing.

Fixed upstream by microsoft/mimalloc@60a1f3b and shipped in mimalloc v3.3.2 (Apr 29). That's why your =0.1.48 pin works — it predates the v3-default flip and bundles the older 3.2.x line.

Opened #164 to bump both submodules — v3.3.1 → v3.3.2 and v2.3.1 → v2.3.2 — same shape as the previous bump (5da8f92). Should resolve this without anyone needing to stay pinned.

Same regression is hitting web-infra-dev/rspack#13925 downstream, since @rspack/binding-win32-arm64-msvc@2.0.1 ships libmimalloc-sys 0.1.47 (mimalloc 3.3.1) as its global allocator.