[lldb-dev] Weird results running lldb under Valgrind

[Greg Clayton via lldb-dev]

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 <dmantipov at 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