问题标签 [thread-sanitizer]

Thread Sanitizer 说点 1 和点 2 之间存在竞争条件。但我不认为存在任何竞争条件，因为 increaseWork.wait() 正在阻塞调用，并且在执行闭包之前它不会通过。

使用 TSAN 构建 QEMU 没有任何问题，但在启动过程中会出现致命问题

它看起来像是 TSAN 的已知问题，并且 --with-coroutine=gthread 似乎在过去有效

但它已被删除（https://patchwork.kernel.org/patch/9704545/）

我尝试了所有 ucontext 和 sigaltstack 后端，但失败了

我的问题是，TSAN 是否仍然适用于当前版本？(qemu 4.2.0)

要检查是否存在我尝试使用的任何线程问题Thread Sanitiser。但是在编辑方案中启用它后，我的应用程序一启动应用程序就会崩溃。下面是堆栈回溯。

我也尝试Strip Style从所有符号更改为调试符号，但无济于事。在这方面的任何建议都会有所帮助。谢谢。

我正在使用无锁堆栈（通过标记指针）来管理一个小块内存池。当块被插入到池中和从池中移除时，列表节点就地创建和销毁。

这是一个非常简化的测试程序，它只从堆栈中弹出。因此，没有 ABA 问题，也没有标记指针。足以证明我正在参加的比赛：

Thread sanitizer 报告以下错误：

当两个线程读取相同的 值时，就会出现问题current_head，但其中一个线程在另一个线程有机会读取之前完成了弹出并覆盖了节点current_head->next。

这类似于这里讨论的问题：为什么“删除”这个无锁堆栈类中的节点会导致竞争条件？除了内存实际上没有被释放。

我知道从机器的角度来看，这种竞争是良性的——如果发生读取竞争，比较和交换将不会成功——但我认为这仍然进入了 C++ 中未定义的行为领域。

1. 有没有办法在没有竞争条件的情况下编写这段代码？
2. 有没有办法注释代码以使线程清理程序忽略它？我尝试过__tsan_acquire但__tsan_release找不到始终有效的东西。

更新我非常确信在标准 C++ 中无法安全地执行原子读取——该对象不再存在。但是——我可以从依赖未定义的行为转向依赖于实现定义的行为吗？考虑到典型的架构和工具链（x86/ARM、gcc/clang），我能做的最好的事情是什么？

更新 2一种似乎可行的特定于实现的方法是用内联汇编替换负载：

这既是体系结构又是编译器特定的——但我认为这确实用“实现定义的”行为取代了“未定义”的行为。

GCC 有许多消毒剂（例如，泄漏、地址、线程）。但是其中许多都需要对代码进行仪表化，并且不能与其他人一起使用。因此，如果在实践中我想应用所有消毒剂以确保我的代码运行良好，那么使用所有这些消毒剂的推荐程序是什么？

我使用 CMake 管理我的项目

这是一个使用 std::condition_variable 的简单示例。使用 clang+tsan 构建以下代码时，

tsan 报告了以下两个问题：

我不明白为什么会报告第一个和第二个警告。

• 第一个警告声称互斥锁被锁定了两次，但这怎么可能呢？互斥锁在持有它时没有被同一个线程锁定，据我所知，这就是 tsan 所声称的。
• 第二个警告表明变量“条件”不是以线程安全的方式读/写的。但是，它只有在互斥锁被锁定时才被读取和写入。还是 condition_variable::wait_for 返回后锁没有锁定？根据https://en.cppreference.com/w/cpp/thread/condition_variable/wait_for，锁应该被锁定。

这可能是 clang/tsan 中的错误吗？我找不到有关此问题的错误报告，并且很难相信情况确实如此。但我根本看不出上面的代码有什么问题。

我使用以下命令编译源代码：

铿锵版本是

我正在使用 Google 的 tsan thread sanitizer 测试一些代码。Tsan 告诉我，我在某个特定函数中存在竞争条件，但是从查看输出中我不清楚问题是什么。是否可以在 gdb 中设置断点以在 tsan 生成警告的地方中断？

对于地址清理器有一个类似的问题，但对于线程清理器，它不起作用，我试图打破 __sanitizer_print_stack_trace，它也不起作用。

hello.cpp 的内容

编译：

这是执行生成的 a.out 文件时来自 TSAN 的错误：

代码按预期运行（我得到了所有的打印），但我不明白为什么我会收到 TSAN 数据竞争警告。如果我注释掉Glib::signal_idle().connect_once行，则没有 TSAN 错误。根据我的阅读，该函数应该可以安全地从任何线程调用。TSAN 是在此处报告误报还是存在真正的数据竞争？

Fedora 31 linux
g++ 10.0.1
glibmm24-2.64.2-1
gtkmm24-2.24.5-9
libtsan-10.2.1-9

这是一个小示例程序：

我编译它（在当前的 Arch Linux 上）：

我无法想象这个程序是如何引起数据竞争的，因为它没有写入，但 TSan 对此非常不满。错误的洪流始于：

这可能只是 TSan 的误报吗？