[LLVMbugs] [Bug 22836] New: libcxx: data race in shared_ptr

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=22836

            Bug ID: 22836
           Summary: libcxx: data race in shared_ptr
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dvyukov at google.com
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

ThreadSanitizer says:

WARNING: ThreadSanitizer: data race (pid=19491)
  Read of size 8 at 0x7d4800017b88 by thread T4 (mutexes: write M188):
    #0 std::__1::__shared_weak_count::lock()
/work/libc++/libcxx/src/memory.cpp:102 (libc++.so.1+0x000000086cc7)
    #1 std::__1::weak_ptr<base::Stream>::lock() const
/opt/clang36/bin/../include/c++/v1/memory:5197 (block_test+0x0000005ae3c9)
    #2 operator()  // std::shared_ptr is passed through std::function (via the
capture list)
    .....

  Previous atomic write of size 8 at 0x7d4800017b88 by thread T3:
    #0 __tsan_atomic64_fetch_add
/work/x/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cc:618
(block_test+0x000000526d07)
    #1 __release_shared /work/libc++/libcxx/src/memory.cpp:61
(libc++.so.1+0x000000086bf6)
    #2 ~shared_ptr /opt/clang36/bin/../include/c++/v1/memory:4462
(block_test+0x00000063b21f)
    #3 operator() // std::shared_ptr is passed through std::function (via the
capture list)
    ....

Both sites contain this pattern:

void f(std::shared_ptr<Thing> b)
{
    Invoke(
        [b]() {
            do_something(b);                                // runs on a
different thread
        });
}

I don't have a full reproducer as it is reported by a ThreadSanitizer user. But
it should be easy to reproduce.

Looking at the shared_ptr sources:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/memory.cpp?revision=224095&view=markup

99    __shared_weak_count*
100    __shared_weak_count::lock() _NOEXCEPT
101    {
102        long object_owners = __shared_owners_;
103        while (object_owners != -1)
104        {
105            if (__sync_bool_compare_and_swap(&__shared_owners_,
106                                             object_owners,
107                                             object_owners+1))
108                return this;
109            object_owners = __shared_owners_;
110        }
111        return 0;
112    }

There is non-atomic load of __shared_owners_ on line 102.

On a related note, why does libcxx use the rudimentary atomic operations
interface instead of std::atomic or at least __atomic_load_n family of
functions? The __sync builtins do not even allow to fix this data race in a
reasonable way.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150307/7780ac41/attachment.html>