thread_local shared_ptr object 在破坏时导致 sigsegv

Question

我有一个程序，它使用thread_local std::shared_ptr来管理一些主要在线程本地访问的对象。 但是，当线程被加入并且线程局部shared_ptr正在析构时，如果程序是由MinGW（Windows 10）编译的，则在调试时总是有SIGSEGV。 这是重现错误的最少代码：

// main.cpp
#include <memory>
#include <thread>

void f() {
    thread_local std::shared_ptr<int> ptr = std::make_shared<int>(0);
}

int main() {
    std::thread th(f);
    th.join();
    return 0;
}

如何编译：

g++ main.cpp -o build\main.exe -std=c++17

编译器版本：

>g++ --version
g++ (x86_64-posix-seh-rev2, Built by MinGW-W64 project) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

使用 gdb 运行，当主线程等待join()时，它将在新线程中提供 SIGSEGV。 当由 gcc、clang (Linux) 和 MSVC (Windows) 编译时，它工作正常。

我尝试调试发现，在调用RtlpWow64SetContextOnAmd64 0xfeeefeee 框架：

RtlpWow64SetContextOnAmd64 0x00007ffd8f4deb5f
RtlpWow64SetContextOnAmd64 0x00007ffd8f4de978
SbSelectProcedure 0x00007ffd8f4ae2e0
CloseHandle 0x00007ffd8ce3655b
pthread_create_wrapper 0x00007ffd73934bac
_beginthreadex 0x00007ffd8e9baf5a
_endthreadex 0x00007ffd8e9bb02c
BaseThreadInitThunk 0x00007ffd8ec87614
RtlUserThreadStart 0x00007ffd8f4c26a1

大会：

...
mov    %rax,(%rdi)
movdqu %xmm0,(%rsi)               ; <------ erased here
call   0x7ffd8f491920             ; <ntdll!RtlReleaseSRWLockShared>
mov    $0x1,%r9d
mov    0x30(%rsp),%rbx
...

后来 shared_ptr 被破坏，当读取0xfeeefeee时有 SIGSEGV。

我想知道：

• 为什么 MinGW（或 Windows 库？）在销毁前擦除线程本地存储？ 在我看来，擦除 memory 应该只在销毁之后发生。 我注意到如果join()被detach()替换，程序正常退出。 也许join()做了一些事情来指示新线程擦除存储？
• 这样的行为是否违反标准？ 我认为标准应该禁止在销毁前擦除 memory。 如果我弄错了，请纠正我。

Answer 1

这是 mingw 中一个长期存在的、公开的已知错误，请参阅 github 上的分析和链接的相应问题： https://github.com/msys2/MINGW-packages/issues/2519

是的，这违反了标准：它不应该崩溃。 正如您已经怀疑的那样，基本上销毁的顺序是不正确的。 0xfeeefeee是HeapFree()用来标记已释放的 memory 的幻数。参见例如这篇文章。

引用lhmouse ：

所以经验法则来了：不要在 GCC 上为 MinGW 目标使用 thread_local。