问题标签 [thread-sanitizer]

我在运行经过线程清理的可执行文件时收到以下错误消息。（我在编译时使用了-fPIC和标志，在可执行时使用了'-pie'标志）：-fsanitized=thread-fsanitize=thread -Wl

但是，通过此 BugZilla 链接后，我检查/proc/sys/kernel/randomize_va_space并启用了值为 2 的随机化。我还指定了通过链接器开关加载 PIE 的位置-Ttext-segment 0x855555000000。

现在我没有更多的致命错误，但我遇到了新的错误消息：

我不知道我在哪里犯了标志错误。任何想法？

考虑以下示例：

编译g++ -fopenmp -fsanitize=thread和运行产量

警告：ThreadSanitizer：数据竞争 (pid=9576)
线程 T1 在 0x7ffdc170f600 读取大小 4：
#0 main._omp_fn.0 (a.out+0x000000400d20)
#1 gomp_thread_start /build/gcc/src/gcc-5.2.0 /libgomp/team.c:118 (libgomp.so.1+0x00000000f42d)

先前由线程 T2 在 0x7ffdc170f600 写入大小 4：
#0 main._omp_fn.0 (a.out+0x000000400d35)
#1 gomp_thread_start /build/gcc/src/gcc-5.2.0/libgomp/team.c:118 (libgomp .so.1+0x00000000f42d)

位置是主线程的堆栈。

主线程在以下位置创建的线程 T1 (tid=9578, running)：
#0 pthread_create /build/gcc/src/gcc-5.2.0/libsanitizer/tsan/tsan_interceptors.cc:895 (libtsan.so.0+0x000000027a37)
# 1 gomp_team_start /build/gcc/src/gcc-5.2.0/libgomp/team.c:796 (libgomp.so.1+0x00000000f98f)
#2 __libc_start_main (libc.so.6+0x00000002060f)

线程 T2 (tid=9579, running) 由主线程在以下位置创建：
#0 pthread_create /build/gcc/src/gcc-5.2.0/libsanitizer/tsan/tsan_interceptors.cc:895 (libtsan.so.0+0x000000027a37)
# 1 gomp_team_start /build/gcc/src/gcc-5.2.0/libgomp/team.c:796 (libgomp.so.1+0x00000000f98f)
#2 __libc_start_main (libc.so.6+0x00000002060f)

摘要：ThreadSanitizer：数据竞争？？：0 main._omp_fn.0

据我所知，这是一个误报。有没有办法避免这种情况？

（使用 clang 和 libomp 也可以。）

我将其归结为一个简单的独立示例。主线程入队 1000 个项目，一个工作线程尝试同时出队。ThreadSanitizer 抱怨其中一个元素的读取和写入之间存在竞争，即使有一个获取-释放内存屏障序列保护它们。

ThreadSanitizer 输出：

命令行：

g++ 版本：5.3.1

谁能解释一下为什么 tsan 认为这是一场数据竞赛？

更新

这似乎是一个误报。为了安抚 ThreadSanitizer，我添加了注释（有关支持的注释，请参见此处，示例请参见此处）。请注意，最近才添加了通过宏在 GCC 中是否启用了 tsan 检测，因此我现在必须手动传递-D__SANITIZE_THREAD__给 g++。

现在 ThreadSanitizer 在运行时很开心。

我遇到了线程清理器 (TSan) 的一些问题，它们抱怨某些生产代码中的数据竞争，其中 std::packaged_task 通过将它们包装在 std::function 中而被移交给调度程序线程。对于这个问题，我简化了它在生产中的作用，同时触发了 TSan。该实现类似于安东尼威廉姆斯在这个问题中给出的答案（至少这是我的理解）：非明显的生命周期问题与 std::promise 和 std::future。

请注意，如果使用 std::promise，则会报告相同的数据竞争。如果一个简单的 int 被抛出/捕获，它也会抱怨。如果在 catch 子句中没有访问异常，则不会发现竞争。如果我省略使用包装 lambda 并简单地将 std::packaged_task 移动到线程，则不会发现任何竞争。

编译时的 TSan 输出clang++-3.6 test_packaged_task.cpp -g3 -std=c++14 -pthread -fsanitize=thread -D_GLIBCXX_DEBUG：

使用 GCC 5.2.1 和 GCC 5.3.1 编译g++ test_packaged_task.cpp -g3 -std=c++14 -pthread -fsanitize=thread -D_GLIBCXX_DEBUG也会产生竞争，但 TSan 输出略有不同：

任何人都可以帮忙吗？这是 TSan 的误报吗？

Xcode 8 包含 Thread Sanitizer，这是一种用于检测竞争条件和其他线程相关问题的工具。

我正在尝试针对我的一个项目运行它，并且正在检测第三方二进制库的许多问题。这些问题压倒了我自己的代码中的任何问题，并且在供应商修复之前我无法替换二进制库。

如何在 Xcode 中为第三方库抑制这些 Thread Sanitizer 警告？

我有一些奇怪的多线程错误，所以我想使用 gcc thread sanitizer 来找到它们。但是，当我-sanitize=thread立即使用以下堆栈跟踪使用生成的二进制段错误进行编译时：

我尝试添加-static-libtsan属性，但现在我收到以下错误：

我怎样才能解决这个问题？我在这里做错了什么？

我正在试验 g++ 和线程消毒剂，我认为我得到了误报。这是真的，还是我犯了一些大错误？

程序（来自 Anthony Williams：C++ Concurrency in Action，第 145 页，清单 5.13）

编译：

g++ 版本

我正进入（状态：

我在更复杂的程序中收到了这个警告，我认为这是我的错误，但现在即使是“教科书程序”也显示相同的行为。是我还是g++（即缺少一些编译器开关）？

更新 取自链接

编译命令

除了性能之外，gcc -fsanitize=thread 缺少 valgrind --tool=helgrind 支持的哪些功能，反之亦然？它依赖于平台吗？

哪个检测到最严重的错误？如果可以的话，我只想使用一个，因为 gcc 线程清理与地址清理不兼容，而 valgrind 使我的项目运行得更慢。

ThreadSanitizer在以下运行的 Swift 程序中检测到数据竞争macOS：

在 iOS 模拟器上运行时，ThreadSanitizer 不会检测到竞态。

ThreadSanitizer 输出：

代码有什么可疑之处吗？

以下代码通过 shared_ptr 同步：

我编译这个

运行此程序时，ThreadSanitizer 给了我以下问题：

我假设 C++ 通过 shared_ptr 引用计数保证足够的同步，通过 shared_ptr 读取永远不会与删除器竞争（对于不同的 shared_ptr 对象）。而且我希望这是很常见的用法，所以我很惊讶 ThreadSanitizer 抱怨这个。

所以这是我的问题：

1. 我的使用安全吗（以及我对 shared_ptr 同步的假设是否正确）？（我希望答案是肯定的，所以现在请关注我的真实问题：）
2. libc++ 是否正确实现了同步？
3. ThreadSanitizer 真的看不到通过引用计数的同步吗？