mimalloc: Crashes with deleting memory allocated in dlls
Overall, we have been quite happy with mimalloc except on windows with applications that use qt. There we get random crashes. The most consistent pattern is in debug builds when hitting the destructor of a std::string that was created within a Qt dll (eg the QString::toStdString). Such crashes can have various cases such as mismatched runtimes, but I think we don’t have that. And disabling mimalloc makes it go away.
We both link in the override dll and include mimalloc-new-delete.h as described in https://microsoft.github.io/mimalloc/overrides.html.
It is not clear to me how that would work in general (how it would intercept new/delete calls in the Qt dll), but my knowledge of the inner workings of dlls is very minimal.
Version 1.6.3 and 1.6.1. Building with make. Visual studio 2017 (various revisions including the most recent).
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 16 (1 by maintainers)
Commits related to this issue
- Fix compatibility with GNU libstdc++ < 9 So far, mimalloc does not override the `nothrow` variants of the `delete` operator because it assumes that their implementation in the C++ standard library re... — committed to sicherha/mimalloc by deleted user 2 years ago
- Fix compatibility with GNU libstdc++ < 9 So far, mimalloc does not override the `nothrow` variants of the `delete` operator because it assumes that their implementation in the C++ standard library re... — committed to sicherha/mimalloc by sicherha 2 years ago
Hi, it looks indeed like a pointer mismatch – which probably means the dynamic override is not working as it should. Can you try to build mimalloc in debug mode? (ie. with -DMI_DEBUG=3). Then run your program with the environment variable
MIMALLOC_VERBOSE=1and you can see if mimalloc was actually redirected. (it should say in the initial output on the console “malloc is redirected”).If this is is not the case, run the
bin/minject --list <myexe>and see if the mimalloc-redirect.dll is high up on the import list; best is right after kernel32. (if it is not, trybin/minject <myexe>and run the new<myexe>-miexecutable that is written to see if that solves the trouble.)Let me know how it goes.
If I were to debug this, my first guess would be that it’s a
malloc/freemismatch. Perhaps step intostrdup_test()and check which allocation functions are actually called.