How could LLDB even function then? We are using the standard std::mutex + std::condition workflow here. Not sure how LLDB could even function if it locking was nor working as expected.
Doing a quick web search, this seems to be due to a mismatched libc++ and libstdc++: https://github.com/google/sanitizers/issues/1259 Greg > On Sep 29, 2020, at 9:46 AM, Dmitry Antipov <dmanti...@yandex.ru> wrote: > > On 9/25/20 5:53 PM, Dmitry Antipov wrote: > >> On 9/24/20 9:14 PM, Greg Clayton wrote: >>> This must be a valgrind issue, there would be major problems if the OS >>> isn't able to lock mutex objects correctly ("mutex is locked simultaneously >>> by two threads"). It is getting confused by a recursive mutex? LLDB uses >>> recursive mutexes. >> LLDB's Predicate.h uses plain std::mutex, which is not recursive, and >> std::lock_guard/std::unique_lock >> on top of it. >> This needs more digging in because the latest Valgrind snapshot reports the >> same "impossible" condition. > > To whom it may be interesting, thread sanitizer reports nearly the same: > > WARNING: ThreadSanitizer: double lock of a mutex (pid=2049545) > #0 pthread_mutex_lock <null> (libtsan.so.0+0x528ac) > #1 __gthread_mutex_lock > /usr/include/c++/10/x86_64-redhat-linux/bits/gthr-default.h:749 > (liblldb.so.12git+0xd725c0) > #2 std::mutex::lock() /usr/include/c++/10/bits/std_mutex.h:100 > (liblldb.so.12git+0xd725c0) > #3 std::lock_guard<std::mutex>::lock_guard(std::mutex&) > /usr/include/c++/10/bits/std_mutex.h:159 (liblldb.so.12git+0xd725c0) > #4 lldb_private::Predicate<bool>::SetValue(bool, > lldb_private::PredicateBroadcastType) > /home/antipov/llvm/source/lldb/include/lldb/Utility/Predicate.h:91 > (liblldb.so.12git+0xd725c0) > #5 lldb_private::EventDataReceipt::DoOnRemoval(lldb_private::Event*) > /home/antipov/llvm/source/lldb/include/lldb/Utility/Event.h:121 > (liblldb.so.12git+0xd725c0) > #6 lldb_private::Event::DoOnRemoval() > /home/antipov/llvm/source/lldb/source/Utility/Event.cpp:82 > (liblldb.so.12git+0xedb7da) > #7 > lldb_private::Listener::FindNextEventInternal(std::unique_lock<std::mutex>&, > lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, > unsigned int, std::shared_ptr<lldb_private::Event>&, bool) > /home/antipov/llvm/source/lldb/source/Utility/Listener.cpp:309 > (liblldb.so.12git+0xee6099) > #8 > lldb_private::Listener::GetEventInternal(lldb_private::Timeout<std::ratio<1l, > 1000000l> > const&, lldb_private::Broadcaster*, lldb_private::ConstString > const*, unsigned int, unsigned int, std::shared_ptr<lldb_private::Event>&) > /home/antipov/llvm/source/lldb/source/Utility/Listener.cpp:357 > (liblldb.so.12git+0xee6b63) > #9 > lldb_private::Listener::GetEventForBroadcaster(lldb_private::Broadcaster*, > std::shared_ptr<lldb_private::Event>&, lldb_private::Timeout<std::ratio<1l, > 1000000l> > const&) > /home/antipov/llvm/source/lldb/source/Utility/Listener.cpp:395 > (liblldb.so.12git+0xee6dea) > #10 > lldb_private::Process::GetEventsPrivate(std::shared_ptr<lldb_private::Event>&, > lldb_private::Timeout<std::ratio<1l, 1000000l> > const&, bool) > /home/antipov/llvm/source/lldb/source/Target/Process.cpp:1139 > (liblldb.so.12git+0xd7931d) > #11 lldb_private::Process::RunPrivateStateThread(bool) > /home/antipov/llvm/source/lldb/source/Target/Process.cpp:3872 > (liblldb.so.12git+0xda3648) > #12 lldb_private::Process::PrivateStateThread(void*) > /home/antipov/llvm/source/lldb/source/Target/Process.cpp:3857 > (liblldb.so.12git+0xda3f87) > #13 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) > /home/antipov/llvm/source/lldb/source/Host/common/HostNativeThreadBase.cpp:68 > (liblldb.so.12git+0xc2c0ea) > #14 <null> <null> (libtsan.so.0+0x2d33f) > > Again, lldb_private::Predicate uses plain std::mutex, which is not recursive. > > Dmitry _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
