Incorrect assertion during memory release in thread (memory allocated in main thread)

[marekkokot]

Hello,
Here is my main.cpp:

#include <thread>
using namespace std;

int main()
{    
    char* a = new char[1ull << 25];    
    thread th([&] {
        delete [] a;
    });
    th.join();    
}

compilation: g++ main.cpp -I mimalloc mimalloc/libmimalloc-debug.a -pthread -o main
run:

./main
mimalloc: assertion failed: at "mimalloc-2.0.0/src/init.c":268, _mi_heap_done
  assertion: "heap->tld->segments.count == 0 || heap->thread_id != _mi_thread_id()"
Aborted (core dumped)

It does not occur in 1.7.0 or in release.
When the alloc size is 1<<22 I get:

mimalloc: warning: mi_usable_size: pointer might not point to a valid heap region: 0x7f4ed4810000
(this may still be a valid very large allocation (over 64MiB))
mimalloc: warning: (yes, the previous pointer 0x7f4ed4810000 was valid after all)
mimalloc: warning: mi_usable_size: pointer might not point to a valid heap region: 0x7f4ed4810000
(this may still be a valid very large allocation (over 64MiB))
mimalloc: warning: (yes, the previous pointer 0x7f4ed4810000 was valid after all)
mimalloc: warning: mi_free: pointer might not point to a valid heap region: 0x7f4ed4810000
(this may still be a valid very large allocation (over 64MiB))
mimalloc: warning: (yes, the previous pointer 0x7f4ed4810000 was valid after all)
mimalloc: warning: mi_usable_size: pointer might not point to a valid heap region: 0x7f4ed4810000
(this may still be a valid very large allocation (over 64MiB))
mimalloc: warning: (yes, the previous pointer 0x7f4ed4810000 was valid after all)
mimalloc: assertion failed: at "/mnt/d/nauka/DEVELOPMENT/3rd-compress/2021-02-16/ONT-compress-dev/3rd-compress/mimalloc-2.0.0/src/init.c":268, _mi_heap_done
  assertion: "heap->tld->segments.count == 0 || heap->thread_id != _mi_thread_id()"
Aborted (core dumped)

For 1 << 21 everything seems to be fine.
Any ideas? Thanks!

[daanx]

Ah interesting! I will look into this -- it may be an over-conservative assertion but not sure; Thanks for the small repro program

[daanx]

Yeah, it is a wrong assertion: since the object is considered "huge" it goes into its own abandoned segment and gets first counted in the original thread (tld->segments.count becomes 2) but it is freed in the other thread which cause the tld->segments.count for that thread to go negative. That is as expected but triggers the assertion. For now, I will disable the assertion but I guess it would be better to count these huge segments in a different way...