Re: [lldb-dev] LLDB got SIGCHLD on hitting the breakpoint
When you say "execute binary code", where exactly is this code being executed? Is it executed by launching another process? Lldb will not automatically debug all child process spawned by your process -- they will run freely. The SIGCHLDs are not coming from lldb -- they are signals which all processes receive (from the operating system) when one of their children dies. They just mean that your process has executed some subprocess and that subprocess has terminated. pl On 21/09/2020 11:48, le wang via lldb-dev wrote: > Hello,everyone: > I've got a problem, when debugging my process with lldb tool on linux > OS(CentOS7).While I use lldb command to set breakpoints, and launch my > process, my process will execute a binary code which contains debug > information, but when my process launched, all breakpoints can not be > hit, The debug process and several received informations like below: > （lldb）target create /home/out/lib/linux64/Debug/appEngine > Current executable set to '/home/out/lib/linux64/Debug/appEngine' > (x86_64) > （lldb）br s -f > /home/out/lib/linux64/Debug/configDB/TestFunctionProcess.cpp -l1 > Breakpoint 1: no locations(pending). > WARNING : Unable to resolve breakpoint to any actual locations. > （lldb）br s -f > /home/out/lib/linux64/Debug/configDB/TestFunctionProcess.cpp -l2 > Breakpoint 2: no locations(pending). > WARNING : Unable to resolve breakpoint to any actual locations. > （lldb）r > Process 4256 launched: '/home/out/lib/linux64/Debug/appEngine' (x86_64) > > Process 4256 stopped and restarted: thread1 received signal: SIGCHLD > Process 4256 stopped and restarted: thread1 received signal: SIGCHLD > Process 4256 stopped and restarted: thread1 received signal: SIGCHLD > Process 4256 stopped and restarted: thread1 received signal: SIGCHLD > Process 4256 stopped and restarted: thread1 received signal: SIGCHLD > Process 4256 stopped and restarted: thread2 received signal: SIGCHLD > > Process stopped and restarted: thread 2 received signal: SIGCHLD > It seems these repeated restart notifications come from lldb, and at > last although my process is executed, it is meaningless. I have checked > that debug information in IR is correct. I have no idea the reason. Can > anyone tell me the reason and how to fix this problem. My lldb version > is 5.0.0, which got from http://www.llvm.org/ with llvm5.0.0 > > > Thanks, > le wang > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Weird results running lldb under Valgrind
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 (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::lock_guard(std::mutex&)
/usr/include/c++/10/bits/std_mutex.h:159 (liblldb.so.12git+0xd725c0)
#4 lldb_private::Predicate::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&, lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int,
std::shared_ptr&, bool) /home/antipov/llvm/source/lldb/source/Utility/Listener.cpp:309 (liblldb.so.12git+0xee6099)
#8 lldb_private::Listener::GetEventInternal(lldb_private::Timeout > const&, lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int,
std::shared_ptr&) /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::Timeout > 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::Timeout > 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 (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
Re: [lldb-dev] Weird results running lldb under Valgrind
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 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 (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::lock_guard(std::mutex&)
> /usr/include/c++/10/bits/std_mutex.h:159 (liblldb.so.12git+0xd725c0)
>#4 lldb_private::Predicate::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&,
> lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int,
> unsigned int, std::shared_ptr&, bool)
> /home/antipov/llvm/source/lldb/source/Utility/Listener.cpp:309
> (liblldb.so.12git+0xee6099)
>#8
> lldb_private::Listener::GetEventInternal(lldb_private::Timeout 100l> > const&, lldb_private::Broadcaster*, lldb_private::ConstString
> const*, unsigned int, unsigned int, std::shared_ptr&)
> /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::Timeout 100l> > 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::Timeout > 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 (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
