std::string destructor causing mimalloc exception

[mvccogo]

Stacktrace:

While assembling a JSON with RapidJSON, a temporary rvalue std::string is created and the C array is copied. When the string is destroyed, the crash happens.

[daanx]

ah, strange error -- looks like the heap pointer is wrong which is very strange. Can you create a repro for testing?

[mvccogo]

@daanx I tried both v2.1.2 and v1.8.2. Unfortunately I wasn't able to test if a standalone RapidJSON would also cause an exception; the pictures are from a plugin which is dynamically linked to a 3rd party application. This was my first attempt at using mimalloc, by including the new-and-delete header. I tried setting a couple of env options, even building it in secure mode, but the error was still happening.

Sorry, I don't know how I would replicate the environment without the 3rd party app. In any case, the call stack is entirely from my plugin. Can the app have somehow affected mimalloc before the call shown here?

[daanx]

What OS is this? I am guessing now that the 3rd party plugin is using a different allocator and a thing allocated with mimalloc/the other allocator is freed by the other. If you don't control the source of the plugin (and it is dynamically loaded) you will need to dynamically override mimalloc as described in the README. (e.g. use mimalloc-redirect on windows or LD_PRELOAD on linux)

[mvccogo]

I'm using Windows 11. I did try mimalloc-redirect (by manually patching my plugin, which is a dll), but it didn't seem to work. Does this mean I'd need to manually patch all binaries from the main app? I believe there might be 30+ modules (main exe + dll modules)... is there a better way of doing this?

For clarification, I do not need mimalloc when upstream modules want to allocate. I simply want to override malloc/new calls from inside my dynamic library.

I can give it a second try by the end of this week and report my results - just wondering which method would be ideal for the scenario depicted.