Mingw support (2022-1)

[SchrodingerZhu]

The old problem was addressed by introducing new way to register clean-up callbacks. However, there are still some works to do. Signed-off-by: Schrodinger ZHU Yifan [email protected]

[SchrodingerZhu]

With MinGW UCRT64 runtime, perf-contention fails with the following stacktrace:

Thread 1 received signal ?, Unknown signal.
0x00007fff84f4e88e in ucrtbase!abort () from C:\WINDOWS\System32\ucrtbase.dll
(gdb) bt
#0  0x00007fff84f4e88e in ucrtbase!abort ()
   from C:\WINDOWS\System32\ucrtbase.dll
#1  0x00007ff69fb65930 in snmalloc::PALWindows::error (
    str=0x7ff69fb76fe0 <snmalloc::NUM_EPOCHS+1496> "assert fail: initialised in D:/snmalloc/src/mem/remotecache.h on 84")
    at D:/snmalloc/src/pal/pal_windows.h:125
#2  0x00007ff69fb6ccf5 in snmalloc::error (
    str=0x7ff69fb76fe0 <snmalloc::NUM_EPOCHS+1496> "assert fail: initialised in D:/snmalloc/src/mem/remotecache.h on 84") at D:/snmalloc/src/pal/pal.h:66
#3  0x00007ff69fb6a881 in snmalloc::RemoteDeallocCache::post<10368ull, snmalloc::Globals> (this=0x23e7ab9da40, local_state=0x23e0001a600,
    id=140697218265472, key=...) at D:/snmalloc/src/mem/remotecache.h:84
#4  0x00007ff69fb656bb in snmalloc::LocalCache::flush<10368ull, snmalloc::Globals, snmalloc::CoreAllocator<snmalloc::Globals>::flush(bool)::{lambda(snmalloc::CapPtr<void, snmalloc::capptr::bound<(snmalloc::capptr::dimension::Spatial)0, (snmalloc::capptr::dimension::AddressSpaceControl)0, (snmalloc::capptr::dimension::Wildness)1> >)#3}>(snmalloc::Globals::LocalState*, snmalloc::CoreAllocator<snmalloc::Globals>::flush(bool)::{lambda(snmalloc::CapPtr<void, snmalloc::capptr::bound<(snmalloc::capptr::dimension::Spatial)0, (snmalloc::capptr::dimension::AddressSpaceControl)0, (snmalloc::capptr::dimension::Wildness)1> >)#3}) (
    this=0x23e7ab9d898, local_state=0x23e0001a600, dealloc=...)
    at D:/snmalloc/src/mem/localcache.h:100
#5  0x00007ff69fb683f4 in snmalloc::CoreAllocator<snmalloc::Globals>::flush (
    this=0x23e00018000, destroy_queue=true)
    at D:/snmalloc/src/mem/corealloc.h:864
#6  0x00007ff69fb67586 in snmalloc::CoreAllocator<snmalloc::Globals>::debug_is_empty_impl (this=0x23e00018000, result=0xe0c4dff316)
    at D:/snmalloc/src/mem/corealloc.h:916
#7  0x00007ff69fb66983 in snmalloc::CoreAllocator<snmalloc::Globals>::debug_is_empty (this=0x23e00018000, result=0xe0c4dff316)
    at D:/snmalloc/src/mem/corealloc.h:964
#8  0x00007ff69fb632b6 in snmalloc::debug_check_empty<snmalloc::Globals> (
    result=0x0) at D:/snmalloc/src/mem/globalalloc.h:118
#9  0x00007ff69fb630e8 in test_tasks (num_tasks=8, count=1048576, size=262144)
    at D:/snmalloc/src/test/perf/contention/contention.cc:145
#10 0x00007ff69fb6320a in main (argc=1, argv=0x23e7ab6cf40)
    at D:/snmalloc/src/test/perf/contention/contention.cc:164

This is only reproducible under debug mode.

[davidchisnall]

Hi, most of these changes seem to be replacing stdio with iostreams. Can you pull those out into a separate PR? Are those things necessary for MinGW or just cleanups?

[mjp41]

Is it definitely using the PTHREAD_DESTRUCTORS for thread cleanup? It looks like it has not properly release the allocators back on thread teardown.

[SchrodingerZhu]

Hi, most of these changes seem to be replacing stdio with iostreams. Can you pull those out into a separate PR? Are those things necessary for MinGW or just cleanups?

It is needed because mingw's gcc disagrees with %zu being a proper format flag.

[SchrodingerZhu]

Is it definitely using the PTHREAD_DESTRUCTORS for thread cleanup? It looks like it has not properly release the allocators back on thread teardown.

unfortunately, the problem persists

[SchrodingerZhu]

I added an output on each pthread-related function entrance: