Created attachment 41382 [details] self contained example Use of C++11 thread_local on mingw64 seems to suffer a use-after-free when the thread_local object is destroyed. The attached code prints "~foo():5" when executed normally. But if it is run through gdb it prints "~foo():feeefeee". "feeefeee" seems to be magic number used by the windows CRT debug HeapFree() to mark deallocated blocks. It seems that the dynamic memory used to store the thread_local object is free'd before the thread_local destructor is called. gcc --version gcc.exe (Rev3, Built by MSYS2 project) 6.3.0
Can confirm for gcc 15.1.0, MSYS2. Exiting a thread with static thread_local std::string variable seems to be randomly causing program termination in about half of cases. Backtrace shows that it's caused by destructing the string, which has __p = 0xfeeefeeefeeefeee, which means that this memory has been freed already.