Hi,
the following scenario:
- Windows
- debug mode
- mimalloc statically built and linked into a (single) DLL
Now, I'm wrapping some mimalloc functions (including those for heap creation/destruction), and those wrapper functions are exported from the DLL and used by an executable.
The wrappers are called from the constructor and destructor of a class, instanced statically in the executable.
Now, when exiting the executable I get a crash when a heap is destroyed by that static instance: the heap object is already destroyed (filled with 0xfd)!
AFAICS this happens because the "FLS cleanup" is happening quite early during exiting, with the destruction of the static instance not yet having happened.
As the FLS cleanup destroys all heaps for the thread this also destroys the heap held in the static instance, and at it's destruction time, it's essentially a heap "double destroy".
I briefly tried the same, but with a dynamically linked mimalloc. This works fine, it appears the "thread detach" cleanup happens late enough here.
My workaround is (currently) to not destroy the heap in the destructor of the class that is statically instanced.
However, this is probably not a general solution...
I guess one approach to remedy this issue could be to perform the "thread cleanup" for the main thread as late as possible (essentially, during process cleanup). Though I wonder whether that would have other implications I may not see...
Any thoughts on the matter?
Hi,
the following scenario:
Now, I'm wrapping some mimalloc functions (including those for heap creation/destruction), and those wrapper functions are exported from the DLL and used by an executable.
The wrappers are called from the constructor and destructor of a class, instanced statically in the executable.
Now, when exiting the executable I get a crash when a heap is destroyed by that static instance: the heap object is already destroyed (filled with 0xfd)!
AFAICS this happens because the "FLS cleanup" is happening quite early during exiting, with the destruction of the static instance not yet having happened.
As the FLS cleanup destroys all heaps for the thread this also destroys the heap held in the static instance, and at it's destruction time, it's essentially a heap "double destroy".
I briefly tried the same, but with a dynamically linked mimalloc. This works fine, it appears the "thread detach" cleanup happens late enough here.
My workaround is (currently) to not destroy the heap in the destructor of the class that is statically instanced.
However, this is probably not a general solution...
I guess one approach to remedy this issue could be to perform the "thread cleanup" for the main thread as late as possible (essentially, during process cleanup). Though I wonder whether that would have other implications I may not see...
Any thoughts on the matter?