[cfe-dev] TSAN shows data race in ~std::shared_ptr

[Ben Pope]

On 18/02/14 16:37, Kostya Serebryany wrote:
> Hi Ben,
>
> Thanks for the test case!
> You've hit this entry of our FAQ:
> https://code.google.com/p/thread-sanitizer/wiki/CppManual#FAQ
> ==================
>
>   * Q: I see what looks like a false report inside the libstdc++
>     (libc++) code.
>
> This may happen in c++11 mode. We are not aware of any such case today,
> but ThreadSanitizer is not heavily tested on code that uses c++11
> threading. A likely solution would 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
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215> before.
>
> ==================

Aha, I think I read this a while ago, but it didn't click.

> Apparently, we now know about one more such case and we'll need to
> update the FAQ. :)

Nice.

> Good news is that this is very easy to fix: just rebuild libc++ with tsan
> by changing the flags in projects/libcxx/lib/buildit.

Fair enough.  I'm using cmake to build, so I added the flag with 
-DLIBCXX_CXX_FEATURE_FLAGS=-fsanitize=thread

I'm getting some undefined symbol: __tsan_init whilst building anything.

If I use the instrumented libc++, would it not have a negative 
performance impact on every application that uses it?  Should I build it 
with a different name and then use -nostdlib -lc++-tsan in my tsan 
specific build?  I guess I could even add libc++ to my projects cmake 
build and link to the one I built as part of that.

> I've just verified that using instrumented libc++ eliminates the tsan
> reports.

Nice.

> If curious, this is happening because shared_ptr<int>::~shared_ptr has
> atomic synchronization in it
> and if tsan does not observe that synchronization it can not properly
> reason about races.

Seems reasonable.

Thanks,

Ben