[lldb-dev] Weird results running lldb under Valgrind
Greg Clayton via lldb-dev
lldb-dev at lists.llvm.org
Thu Sep 24 11:14:17 PDT 2020
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.
> On Sep 24, 2020, at 1:55 AM, Dmitry Antipov via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>
> Does anyone has an explanation of this weird run of 'valgrind --tool=drd':
>
> ==2715== drd, a thread error detector
> ==2715== Copyright (C) 2006-2017, and GNU GPL'd, by Bart Van Assche.
> ==2715== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
> ==2715== Command: /home/antipov/.local/llvm-12.0.0/bin/lldb
> ==2715== Parent PID: 1702
>
> In LLDB, do 'process attach --pid [PID of running Firefox]', then:
>
> ==2715== Thread 5:
> ==2715== The impossible happened: mutex is locked simultaneously by two threads: mutex 0xe907d10, recursion count 1, owner 1.
> ==2715== at 0x4841015: pthread_mutex_lock_intercept (drd_pthread_intercepts.c:893)
> ==2715== by 0x4841015: pthread_mutex_lock (drd_pthread_intercepts.c:903)
> ==2715== by 0x504FBEE: __gthread_mutex_lock (gthr-default.h:749)
> ==2715== by 0x504FBEE: lock (std_mutex.h:100)
> ==2715== by 0x504FBEE: lock_guard (std_mutex.h:159)
> ==2715== by 0x504FBEE: SetValue (Predicate.h:91)
> ==2715== by 0x504FBEE: lldb_private::EventDataReceipt::DoOnRemoval(lldb_private::Event*) (Event.h:121)
> ==2715== by 0x5113644: 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) (Listener.cpp:309)
> ==2715== by 0x5113DD1: 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>&) (Listener.cpp:357)
> ==2715== by 0x5113F4A: lldb_private::Listener::GetEventForBroadcaster(lldb_private::Broadcaster*, std::shared_ptr<lldb_private::Event>&, lldb_private::Timeout<std::ratio<1l, 1000000l> > const&) (Listener.cpp:395)
> ==2715== by 0x506ADD4: lldb_private::Process::RunPrivateStateThread(bool) (Process.cpp:3872)
> ==2715== by 0x506B3F5: lldb_private::Process::PrivateStateThread(void*) (Process.cpp:3857)
> ==2715== by 0x483DB9A: vgDrd_thread_wrapper (drd_pthread_intercepts.c:449)
> ==2715== by 0x488B3F8: start_thread (in /usr/lib64/libpthread-2.32.so)
> ==2715== by 0xDFCEA92: clone (in /usr/lib64/libc-2.32.so)
> ==2715== mutex 0xe907d10 was first observed at:
> ==2715== at 0x4840F55: pthread_mutex_lock_intercept (drd_pthread_intercepts.c:890)
> ==2715== by 0x4840F55: pthread_mutex_lock (drd_pthread_intercepts.c:903)
> ==2715== by 0x5058502: __gthread_mutex_lock (gthr-default.h:749)
> ==2715== by 0x5058502: lock (std_mutex.h:100)
> ==2715== by 0x5058502: lock (unique_lock.h:138)
> ==2715== by 0x5058502: unique_lock (unique_lock.h:68)
> ==2715== by 0x5058502: WaitFor<lldb_private::Predicate<T>::WaitForValueEqualTo<bool>::<lambda(bool)> > (Predicate.h:123)
> ==2715== by 0x5058502: WaitForValueEqualTo (Predicate.h:157)
> ==2715== by 0x5058502: WaitForEventReceived (Event.h:114)
> ==2715== by 0x5058502: lldb_private::Process::ControlPrivateStateThread(unsigned int) (Process.cpp:3698)
> ==2715== by 0x505BC61: lldb_private::Process::StartPrivateStateThread(bool) (Process.cpp:3647)
> ==2715== by 0x5065B96: lldb_private::Process::Attach(lldb_private::ProcessAttachInfo&) (Process.cpp:2961)
> ==2715== by 0x544DBB8: PlatformPOSIX::Attach(lldb_private::ProcessAttachInfo&, lldb_private::Debugger&, lldb_private::Target*, lldb_private::Status&) (PlatformPOSIX.cpp:401)
> ==2715== by 0x509F531: lldb_private::Target::Attach(lldb_private::ProcessAttachInfo&, lldb_private::Stream*) (Target.cpp:3008)
> ==2715== by 0x54C3F17: CommandObjectProcessAttach::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) (CommandObjectProcess.cpp:386)
> ==2715== by 0x4FC0ACD: lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) (CommandObject.cpp:993)
> ==2715== by 0x4FBCBD7: lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, lldb_private::ExecutionContext*, bool, bool) (CommandInterpreter.cpp:1803)
> ==2715== by 0x4FBDB96: lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (CommandInterpreter.cpp:2838)
> ==2715== by 0x4EF21C0: lldb_private::IOHandlerEditline::Run() (IOHandler.cpp:579)
> ==2715== by 0x4ED02B0: lldb_private::Debugger::RunIOHandlers() (Debugger.cpp:861)
>
> Hopefully this is an issue with valgrind and not lldb. But still curious whether someone else can reproduce something similar.
>
> Dmitry
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
More information about the lldb-dev
mailing list