build openjdk with fsanitizer=thread

[Dmitry Vyukov]

This is puzzling. It seems to be protected by the PlatformMutex, which
is pthread_mutex_t underneath:
https://github.com/openjdk/jdk/blob/0da0333a06aef32ce7af3448dfa38c1f40c32826/src/hotspot/os/posix/os_posix.inline.hpp

Tsan does understand pthread_mutex_t, that's a very widely used
functionality. So there is something fishy going on.
Do we know that it intercepts/understands at least some of pthread
mutexes? Or there is some systematic problem which results in tsan
missing just all of pthread? By any chance don't you have something
like "called_from_lib:pthread" in your tsan.supp?

There is also something fishy in the reports  you posted. First one
happens inside of MutexLocker::~MutexLocker(). The question is: why
the race wasn't reported in the MutexLocker constructor where we write
to owner_ as well? I don't see any reasonable execution where write in
ctor does not race, but write in dtor races...
The same in the second report: the race is in notify method, but we
also called lock before which write to owner_. Why that did not
race?...




On Wed, Feb 26, 2020 at 3:11 PM Jie He <Jie.He at arm.com> wrote:
>
> Oh, I misunderstand the race object,
> but _owner also appears to be protected by the member var _lock within class Mutex.
>
> -----Original Message-----
> From: Dmitry Vyukov <dvyukov at google.com>
> Sent: Wednesday, February 26, 2020 9:56 PM
> To: Jie He <Jie.He at arm.com>
> Cc: Arthur Eubanks <aeubanks at google.com>; tsan-dev at openjdk.java.net; nd <nd at arm.com>; thread-sanitizer <thread-sanitizer at googlegroups.com>
> Subject: Re: build openjdk with fsanitizer=thread
>
> On Wed, Feb 26, 2020 at 2:46 PM Jie He <Jie.He at arm.com> wrote:
> >
> > Is this case you mentioned "_owned_by_self"
> >
> > >     #0 Mutex::owned_by_self() const /home/wave/workspace/jdk_master/src/hotspot/share/runtime/mutex.cpp:301:10 (libjvm.so+0x1925966)
> > >     #1 assert_lock_strong(Mutex const*) /home/wave/workspace/jdk_master/src/hotspot/share/runtime/mutexLocker.cpp:187:13 (libjvm.so+0x19272fa)
> > >     #2 MutexLocker::~MutexLocker() /home/wave/workspace/jdk_master/src/hotspot/share/runtime/mutexLocker.hpp:237:7 (libjvm.so+0x33da8a)
> > >     #3 G1YoungRemSetSamplingThread::stop_service() /home/wave/workspace/jdk_master/src/hotspot/share/gc/g1/g1YoungRemSetSamplingThread.cpp:129:1 (libjvm.so+0x10c50e0)
> > >     #4 ConcurrentGCThread::stop() /home/wave/workspace/jdk_master/src/hotspot/share/gc/shared/concurrentGCThread.cpp:65:3 (libjvm.so+0xc9fa11)
> > >     #5 G1CollectedHeap::stop() /home/wave/workspace/jdk_master/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:1867:31 (libjvm.so+0xfae058)
> > >     #6 before_exit(JavaThread*) /home/wave/workspace/jdk_master/src/hotspot/share/runtime/java.cpp:461:21 (libjvm.so+0x1215b84)
> > >     #7 Threads::destroy_vm() /home/wave/workspace/jdk_master/src/hotspot/share/runtime/thread.cpp:4418:3 (libjvm.so+0x1e326ee)
> > >     #8 jni_DestroyJavaVM_inner(JavaVM_*) /home/wave/workspace/jdk_master/src/hotspot/share/prims/jni.cpp:3989:7 (libjvm.so+0x137a5eb)
> > >     #9 jni_DestroyJavaVM /home/wave/workspace/jdk_master/src/hotspot/share/prims/jni.cpp:4007:14 (libjvm.so+0x137a3ef)
> > >     #10 JavaMain
> >
> > Seems thread::current() is a TLS variable, refer to the code:
> >
> > inline Thread* Thread::current_or_null() { #ifndef
> > USE_LIBRARY_BASED_TLS_ONLY
> >   return _thr_current;
> > #else
> >   if (ThreadLocalStorage::is_initialized()) {
> >     return ThreadLocalStorage::thread();
> >   }
> >   return NULL;
> > #endif
> > }
>
> The race is on Mutex::owner_ based on the fact that another thread does a write, and on allocation stack, and the race just seems to be visible in the code and is a common race.