Where is the data race in this simple c++ code

Question

Both clang++ and g++ sanitizers produce similar warning about data race for this simple code. Is it a false alarm? What is the problem?

Code:

#include <thread>
struct A
{
    void operator()()
    {
    }
};

struct B
{
    void operator()()
    {
    }
};

int main(void)
{
    // callable objects are created and moved into thread
    std::thread t1(A{});
    std::thread t2(B{});
    t1.join();
    t2.join();
    return 0;
}

Compile flags:

-pthread -O0 -g -fsanitize=thread -fsanitize=undefined

Sanitizer output for g++:

==================
WARNING: ThreadSanitizer: data race (pid=80173)
  Write of size 8 at 0x7b0400000800 by thread T2:
    #0 pipe ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1726 (libtsan.so.0+0x3ea28)
    #1 __sanitizer::IsAccessibleMemoryRange(unsigned long, unsigned long) ../../../../src/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:276 (libubsan.so.1+0x20102)
    #2 std::thread::_State_impl<std::thread::_Invoker<std::tuple<B> > >::~_State_impl() /usr/include/c++/11/bits/std_thread.h:201 (a.out+0x5191)
    #3 <null> <null> (libstdc++.so.6+0xdc2cb)

  Previous write of size 8 at 0x7b0400000800 by thread T1:
    #0 pipe ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1726 (libtsan.so.0+0x3ea28)
    #1 __sanitizer::IsAccessibleMemoryRange(unsigned long, unsigned long) ../../../../src/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:276 (libubsan.so.1+0x20102)
    #2 std::thread::_State_impl<std::thread::_Invoker<std::tuple<A> > >::~_State_impl() /usr/include/c++/11/bits/std_thread.h:201 (a.out+0x53a5)
    #3 <null> <null> (libstdc++.so.6+0xdc2cb)

  Thread T2 (tid=80176, running) created by main thread at:
    #0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:969 (libtsan.so.0+0x605b8)
    #1 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) <null> (libstdc++.so.6+0xdc398)
    #2 main a.cpp:20 (a.out+0x3396)

  Thread T1 (tid=80175, finished) created by main thread at:
    #0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:969 (libtsan.so.0+0x605b8)
    #1 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) <null> (libstdc++.so.6+0xdc398)
    #2 main a.cpp:19 (a.out+0x3383)

SUMMARY: ThreadSanitizer: data race ../../../../src/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:276 in __sanitizer::IsAccessibleMemoryRange(unsigned long, unsigned long)
==================
ThreadSanitizer: reported 1 warnings

Note: This warning is given only when thread and UB sanitizers are both enabled.

It looks like g++ is complaining that two empty ranges overlap — Caleth, Jul 27 '22 at 10:49
My guess would be thread sanitizer finding errors in the instrumented code by UB sanitizer. — Quimby, Jul 27 '22 at 10:50
fyi - if you pass`-stdlib=libc++` to clang it doesn't complain. So could be in the std library code. — Richard Critten, Jul 27 '22 at 10:58
clang++ version: `Ubuntu clang version 14.0.0-1ubuntu1`, and g++ version: `g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0` — Özgür Murat Sağdıçoğlu, Jul 27 '22 at 11:25
Note that some combinations of sanitizers are not allowed such as `-fsanitize=thread` cannot be combined with `-fsanitize=address`, or `-fsanitize=leak` (written in gcc doc). But I could not find any restriction for combining `-fsanitize=thread` and `-fsanitize=undefined`. — Özgür Murat Sağdıçoğlu, Jul 27 '22 at 11:32
@Eljay adding `-std=c++17` did not change anything for both gcc and clang. — Özgür Murat Sağdıçoğlu, Jul 27 '22 at 11:54
Threads not sharing any data, as well as both routines empty e.g. immutable - this code don't have any data race and cannot have any. Warning is from library you've linked over here `san_interceptors_posix.cpp:1726` — Victor Gubin, Jul 27 '22 at 13:19
Should be easy to test if the error is caused by the empty classes overlapping: Make them not empty. — Goswin von Brederlow, Jul 27 '22 at 19:22
@GoswinvonBrederlow tried it with integer members but it is same. — Özgür Murat Sağdıçoğlu, Jul 28 '22 at 04:50

score 12 · Accepted Answer · answered Jul 27 '22 at 13:28

The program is well-formed. It doesn't have any data race or other undefined behavior and it also doesn't have any race condition or unspecified behavior (except for the possibility of aborting with an uncaught exception if thread creation fails).

Thread sanitizer is simply not playing nice with the undefined behavior sanitizer. Whether they are meant to be usable together I am not sure. I have had issues like this before when combining them and so would recommend not doing that.

If they are meant to play nicely together, then this would indeed be a bug.

I made a trial on Xcode scheme setup GUI. Xcode allows you to select both Address and Undefined behavior sanitizers, or Thread and Undefined behavior sanitizers. But not Address and Thread sanitizers together. This seems to indicate that OP use case is legitimate. — prapin, Jul 27 '22 at 18:29

score 3 · Answer 2 · edited Aug 05 '22 at 19:57

From this repo

Non-instrumented code

ThreadSanitizer generally requires all code to be compiled with -fsanitize=thread. If some code (e.g. dynamic libraries) is not compiled with the flag, it can lead to false positive race reports, false negative race reports and/or missed stack frames in reports depending on the nature of non-instrumented code. To not produce false positive reports ThreadSanitizer has to see all synchronization in the program, some synchronization operations (namely, atomic operations and thread-safe static initialization) are intercepted during compilation (and can only be intercepted during compilation). ThreadSanitizer stack trace collection also relies on compiler instrumentation (unwinding stack on each memory access is too expensive).

From this FAQ entry

FAQ

Q: I see what looks like a false report inside the libstdc++ (libc++) code.

This may happen in c++11 mode. One such case is discussed here. Note that ThreadSanitizer is not yet heavily tested on code that uses c++11 threading. The solution is be to rebuild libstdc++ (libc++) with ThreadSanitizer (this might be tricky, and the process changes periodically; contact us for details). It is also possible that libstdc++ (libc++) has a bug, we've seen at least one such before.

Where is the data race in this simple c++ code

2 Answers2

Non-instrumented code

FAQ