TSAN: data tace in std::__shared_count with clang's thread sanitizer and gcc's libstdc++

[guoshusong]

hi, I use thread sanitizer with clang1101, and I use Clang11 to compile my code, but I use gcc830's libstdc++ instead of llvm's libc++. Thera is a report about data race in std::__shared_count.

`==================
WARNING: ThreadSanitizer: data race (pid=11752)
Read of size 8 at 0x7b1c0035c570 by thread T2604:
#0 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::_M_swap(std::__shared_count<(__gnu_cxx::_Lock_policy)2>&) x86_64-x86_64-gcc-830/lib/gcc/x86_64-linux-gnu/8.3.0/../../../../include/c++/8.3.0/bits/shared_ptr_base.h:756:37 (thrift+0x193d9583)
#1 std::__shared_ptr<folly::RequestContext, (__gnu_cxx::_Lock_policy)2>::__shared_ptr(std::__shared_ptr<folly::RequestContext, (__gnu_cxx::_Lock_policy)2>&&) (thrift+0x19e92433)
#2 execute_native_thread_routine /data00/jenkins/workspace/gcc8_x86_64/src/gcc/libstdc++-v3/src/c++11/thread.cc:80:18 (libstdc++.so.6+0xc3a6e)

Previous write of size 8 at 0x7b1c0035c570 by thread T2605:
#0 operator new(unsigned long) llvm-project/src/llvm-project/compiler-rt/lib/tsan/rtl/tsan_new_delete.cpp:64:3 (thrift+0x4208977)
#1 std::_MakeUniq<folly::NotificationQueuefolly::AsyncServerSocket::QueueMessage::Node>::__single_object std::make_unique<folly::NotificationQueuefolly::AsyncServerSocket::QueueMessage::Node, folly::AsyncServerSocket::QueueMessage, std::shared_ptrfolly::RequestContext >(folly::AsyncServerSocket::QueueMessage&&, std::shared_ptrfolly::RequestContext&&) /usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/unique_ptr.h:831:30 (hrift+0x1a15054b)
#2 execute_native_thread_routine /data00/jenkins/workspace/gcc8_x86_64/src/gcc/libstdc++-v3/src/c++11/thread.cc:80:18 (libstdc++.so.6+0xc3a6e)

Location is heap block of size 104 at 0x7b1c0035c510 allocated by thread T2605:
#0 operator new(unsigned long) llvm-project/src/llvm-project/compiler-rt/lib/tsan/rtl/tsan_new_delete.cpp:64:3 (thrift+0x4208977)
#1 std::_MakeUniq<folly::NotificationQueuefolly::AsyncServerSocket::QueueMessage::Node>::__single_object std::make_unique<folly::NotificationQueuefolly::AsyncServerSocket::QueueMessage::Node, folly::AsyncServerSocket::QueueMessage, std::shared_ptrfolly::RequestContext >(folly::AsyncServerSocket::QueueMessage&&, std::shared_ptrfolly::RequestContext&&) /usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/unique_ptr.h:831:30 (thrift+0x1a15054b)
#2 execute_native_thread_routine gcc8_x86_64/src/gcc/libstdc++-v3/src/c++11/thread.cc:80:18 (libstdc++.so.6+0xc3a6e)

Thread T2604 'io1' (tid=15391, running) cre/llvm-project/src/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:966:3 (apollo_sort_aweme_archon_thrift+0x4198c5b)
#0 pthread_create llvm-project/src/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:966:3 (thrift+0x4198c5b)
#1 __gthread_create gcc8_x86_64/gcc-build/x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu/bits/gthr-default.h:662:35 (libstdc++.so.6+0xc3cf4)
#2 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_deletestd::thread::_State >, void (*)()) gcc8_x86_64/src/gcc/libstdc++-v3/src/c++11/thread.cc:135:37 (libstdc++.so.6+0xc3cf4)
#3 folly::NamedThreadFactory::newThread(folly::Function<void ()>&&) folly/include/folly/executors/thread_factory/NamedThreadFactory.h:37:12 (thrift+0x191a5402)
#4 folly::ThreadPoolExecutor::addThreads(unsigned long) folly/folly/executors/ThreadPoolExecutor.cpp:192:38 (thrift+0x1a0139a0)
......

Thread T2605 'Acceptor Thread' (tid=15392, running) created by main thread at:
#0 pthread_create llvm-project/src/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:966:3 (thrift+0x4198c5b)
#1 __gthread_create gcc8_x86_64/gcc-build/x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu/bits/gthr-default.h:662:35 (libstdc++.so.6+0xc3cf4)
#2 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_deletestd::thread::_State >, void (*)()) gcc8_x86_64/src/gcc/libstdc++-v3/src/c++11/thread.cc:135:37 (libstdc++.so.6+0xc3cf4)
#3 folly::NamedThreadFactory::newThread(folly::Function<void ()>&&) folly/include/folly/executors/thread_factory/NamedThreadFactory.h:37:12 (thrift+0x191a5402)
#4 folly::ThreadPoolExecutor::addThreads(unsigned long) folly/folly/executors/ThreadPoolExecutor.cpp:192:38 (thrift+0x1a0139a0)
#5 wangle::ServerBootstrap<wangle::Pipeline<folly::IOBufQueue&, std::unique_ptr<folly::IOBuf, std::default_deletefolly::IOBuf > > >::bind(int) wangle/include/wangle/bootstrap/ServerBootstrap.h:208:5 (thrift+0x199db631)
.......

SUMMARY: ThreadSanitizer: data race /x86_64-x86_64-gcc-830/lib/gcc/x86_64-linux-gnu/8.3.0/../../../../include/c++/8.3.0/bits/shared_ptr_base.h:756:37 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::_M_swap(std::__shared_count<(__gnu_cxx::_Lock_policy)2>&)
==================`

I think this is a false positive.
Cloud you tell me how to fix this problem or Suppress this error?
Thanks!

[kcc]

I don't remember if we ever tested tsan with libstdc++.
The main problem is not libstdc++ vs libc++ though.
tsan requires that you instrument all the code in the process that may have atomics - otherwise it will have false positives.
In this case, I expect that some atomics are being executed in the libstdc++.so binary that was not tsan-instrumented.

@dvyukov for a better answer.

[dvyukov]

As @kcc said this can be fixed by building tsan-instrumented libc++ or suppressed using, well, suppressions:
https://github.com/google/sanitizers/wiki/ThreadSanitizerSuppressions
for some shared_ptr-related frame (preferably using race_top type).

[jwakely]

(Sorry for the necro-thread)

In this case, I expect that some atomics are being executed in the libstdc++.so binary that was not tsan-instrumented.

Yes, but the stack traces shown make no sense. Libstdc++ stopped using std::shared_ptr in std::thread with GCC 6.1, so with the reporter's GCC 8 there should be no uninstrumented atomics when creating a std::thread, and so no tsan errors for __shared_count. The stack traces seem to be a weird mix of symbols from GCC 5 and GCC 8 that I don't understand. I don't think this is a tsan or libstdc++ bug though.