Mimalloc aligned allocations sometimes returns the wrong alignment in 5.6

After moving to 5.6.1, we started getting assertions where we had code validating that memory returned from FMemory::Malloc() returned the proper alignment, in our case 16 byte alignment for SIMD.

The specific issue we had was happening during a commandlet that was generating NavMesh for Havok. There was an allocation that was 61456 bytes with 16 byte alignment. It was getting 8 byte alignment (Win64 default alignment) back from Mimalloc in the commandlet (Editor). This was happening on Windows Server 2025, and there’s a good chance it just doesn’t happen on Wine/Linux.

I did some digging and found that Mimalloc had a change to it about a year ago that just shipped with 5.6 in its aligned allocation codepath. I reverted that change and this assert went away entirely. I dug into it more and found that more modern versions of Mimalloc handle this exact case when asking the OS for aligned memory and will fallback to an overallocation and manual alignment in that case.

Change that introduced this issue: https://github.com/EpicGames/UnrealEngine/commit/21a903b6f6c90f8f804715976e1991e3b8c99237

Snippet where newer versions of Mimalloc handle the wrong alignment returned: https://github.com/EpicGames/UnrealEngine/blob/6978b63c8951e57d97048d8424a0bebd637dde1d/Engine/Source/ThirdParty/mimalloc/2\.1\.2/src/os.c\#L237\-L281

Are there plans to move to a newer version of Mimalloc anytime soon? There are lots of features and bug fixes like this particular issue that I’d love to see in Unreal.

Steps to Reproduce
I wasn’t able to put together a repro on my Windows workstation, as it was hard to tell if this was related to the servers with several hundred GB of RAM and the nature of the commandlet making lots of large aligned allocations, or what.

Windows Server 2025

768 GB of RAM

Process had ~80gb of used RAM at the time of crash

Hi Bill,

It is surprising that we never heard of this bug before. The function that is supposed to handle the alignment in the 2.0 version is this one mi_os_mem_alloc_aligned. The one where we made the change just takes a hints and doesn’t require the block to actually be aligned. So something else must be going on.

If you have some time to gather a bit more evidence on what is actually going on would be great.

Upgrading third party libraries as widely used as this one is a very complex endeavor which requires a lot of benchmarks to make sure we get no performance or any other kind of regression in any of our workloads. This is not on our roadmap for the short term. It would be preferable to get to the bottom of this first in order to better understand the root cause.

Thanks

Danny