mimalloc is linked directly into a Windows DLL that can be truly unloaded via FreeLibrary. In this configuration, HLK/AppVerifier reports leaked virtual reservations during DLL unload, with stacks pointing into mimalloc initialization / arena management. This does not reproduce on normal process exit; it reproduces on true DLL unload (DLL_PROCESS_DETACH with lpReserved == NULL).
Our integration is a direct static/link-time integration of mimalloc into the target DLL. We do not post-process the DLL with minject.exe, and we do not use a separate mimalloc redirect/replacement DLL.
From investigation, this appears to be a teardown-order issue on Windows. Cleanup during normal DLL_PROCESS_DETACH seems too early in this scenario, and relying on default destroy-on-exit behavior is not sufficient. If we suppress destroy-on-exit during detach, note that a true unload is happening, and then invoke mimalloc teardown once from a later CRT callback, the AppVerifier leak report goes away. That suggests explicit mimalloc teardown may require a late unload point, after CRT on-exit handlers and dynamic destructors, rather than direct execution during ordinary DLL detach.
Environment: Windows, DLL linked directly with mimalloc, unload triggered by FreeLibrary, leak detected by AppVerifier / HLK-style validation.
Questions:
Is this a known limitation when mimalloc is statically linked directly into a dynamically unloaded Windows DLL?
Is there a recommended/supported teardown pattern for true DLL unload?
Is there an officially supported way to run mimalloc cleanup from a late unload callback on Windows?
Any guidance or recommendations on the correct/supported way to handle this scenario would be greatly appreciated.
mimalloc is linked directly into a Windows DLL that can be truly unloaded via FreeLibrary. In this configuration, HLK/AppVerifier reports leaked virtual reservations during DLL unload, with stacks pointing into mimalloc initialization / arena management. This does not reproduce on normal process exit; it reproduces on true DLL unload (DLL_PROCESS_DETACH with lpReserved == NULL).
Our integration is a direct static/link-time integration of mimalloc into the target DLL. We do not post-process the DLL with minject.exe, and we do not use a separate mimalloc redirect/replacement DLL.
From investigation, this appears to be a teardown-order issue on Windows. Cleanup during normal DLL_PROCESS_DETACH seems too early in this scenario, and relying on default destroy-on-exit behavior is not sufficient. If we suppress destroy-on-exit during detach, note that a true unload is happening, and then invoke mimalloc teardown once from a later CRT callback, the AppVerifier leak report goes away. That suggests explicit mimalloc teardown may require a late unload point, after CRT on-exit handlers and dynamic destructors, rather than direct execution during ordinary DLL detach.
Environment: Windows, DLL linked directly with mimalloc, unload triggered by FreeLibrary, leak detected by AppVerifier / HLK-style validation.
Questions:
Is this a known limitation when mimalloc is statically linked directly into a dynamically unloaded Windows DLL?
Is there a recommended/supported teardown pattern for true DLL unload?
Is there an officially supported way to run mimalloc cleanup from a late unload callback on Windows?
Any guidance or recommendations on the correct/supported way to handle this scenario would be greatly appreciated.