Unreasonable claims about robustness of hooking.

[pmsjt]

It also includes a robust way to override the default allocator in Windows

This is a misleading claim. There is no reality under which depending on redirect all malloc/free calls that go through the (dynamic) C runtime allocator, including those from other DLL's or libraries equates to robustness. The number of allocation APIs is a moving target. At any moment this library will be an API behind whether it is external and documented to internal and undocumented.

The text should be revised more realistically disclose the risk inherent with dependency on detouring.

[daanx]

Ah, yes, I agree -- I'll update it and try to rephrase it more concisely. However, at the moment the redirection is used for quite a few (very) large programs and services that consist of many (3rd party) components and dll's etc. and it works quite well for them -- in that sense, it is robust. (but I understand what you are saying).

Now, of course, it would be even better if the Windows API's would evolve to have an official way to override the memory allocator efficiently.

[pmsjt]

Thank you.

I am presently looking at a series of crashes from x86-64 programs running on Arm64 (under Prism). I see that the library hooked the APIs and it is being called as expected, but it is crashing on a "free", whilst trying to parse the allocations metadata. My suspicion is that the allocation somehow made it to the Windows provided allocator and the metadata used by it is foreign to this library.

Even if it had worked, detouring all heap allocations to emulated code would have probably had a measurable perf overhead. I wonder if a sensible thing to do would be for the library to elect not to inject when detecting that is running under emulation and, instead, let the Windows allocator do its thing which will be safer and faster.

[daanx]

Thanks -- I am not sure I entirely understand the bug you are looking at; is this a program using mimalloc.dll and mimalloc-redirect.dll on arm64 in x64 emulation? If so, that will not work unfortunately (and even it it would work, the performance would not be good). The way to do this is either to just not provide mimalloc-redirect.dll (which would make it use the standard allocator), or otherwise, to compile mimalloc.dll as arm64ec code, and then use mimalloc-redirect-arm64ec.dll -- see the bin directory for more information. Not sure if this is what you are looking at but just in case.

[pmsjt]

In the crashes I see mimalloc-override.

[daanx]

Ah, mimalloc.dll was called mimalloc-override.dll in earlier mimalloc version (pre v2.1.9, v1.8.9). Feel free to ping me in teams if needed. Thanks.