[lldb-dev] Hang during attach
David Jones via lldb-dev
lldb-dev at lists.llvm.org
Fri Jan 8 17:42:31 PST 2016
I have some code which worked under LLVM+LLDB 3.6.0 which runs as follows:
its purpose is to run some code, and print a backtrace if the code
segfaults. My approach was:
- fork
- the child runs the main part of the program.
- the parent creates a debugger and attaches to the child. The child is
continued and allowed to run until either it terminates or faults.
This code worked in 3.6.0:
switch (pid = fork()) {
case -1:
return; // no trace
case 0:
// child
fprintf(stderr, "child 1\n");
//pause();
fprintf(stderr, "child 2\n");
signal(SIGUSR1, SIG_DFL);
fprintf(stderr, "child 3\n");
return;
default:
// parent: create debugger
{
StateType state;
//SBAttachInfo ai(pid);
SBDebugger::Initialize();
m_Debugger = SBDebugger::Create(false);
if (!m_Debugger.IsValid())
fprintf (stderr, "error: failed to create a debugger
object\n");
m_Debugger.SetAsync(false);
m_Listener = m_Debugger.GetListener();
m_Target = m_Debugger.CreateTarget(exec_name);
fprintf(stderr, "parent 1\n");
//m_Target.Attach(ai, m_Error);
m_Target.AttachToProcessWithID(m_Listener, pid, m_Error);
fprintf(stderr, "parent 2\n");
Under LLVM+LLDB 3.7.1, I see the following instead:
- the child runs to completion (child 1/2/3 messages print out).
- the parent hangs in attach (parent 1 prints out but parent 2 does not)
Debugging the whole thing under GDB (unsure how reliable this is, but the
hang happens w/o GDB as well) shows:
child 1
child 2
child 3
[ child prints out other stuff and runs happily ]
parent 1
[ child terminates ]
[New Thread 0x7fffed043700 (LWP 470)]
[New Thread 0x7fffec842700 (LWP 472)]
[Thread 0x7fffec842700 (LWP 472) exited]
^C
Program received signal SIGINT, Interrupt.
0x00007ffff2bd566b in pthread_join (threadid=140737169864448,
thread_return=0x0)
at pthread_join.c:92
92 pthread_join.c: No such file or directory.
(gdb) bt
#0 0x00007ffff2bd566b in pthread_join (threadid=140737169864448,
thread_return=0x0) at pthread_join.c:92
#1 0x00007ffff5f8247c in lldb_private::HostThreadPosix::Join(void**) ()
from /tools/llvm/3.7.1dbg/lib/liblldb.so
#2 0x00007ffff5f7034d in lldb_private::HostThread::Join(void**) ()
from /tools/llvm/3.7.1dbg/lib/liblldb.so
#3 0x00007ffff610802e in
lldb_private::process_gdb_remote::GDBRemoteCommunication::StartDebugserverProcess(char
const*, unsigned short, lldb_private::ProcessLaunchInfo&, unsigned short&)
() from /tools/llvm/3.7.1dbg/lib/liblldb.so
#4 0x00007ffff612f5c0 in
lldb_private::process_gdb_remote::ProcessGDBRemote::LaunchAndConnectToDebugserver(lldb_private::ProcessInfo
const&) ()
from /tools/llvm/3.7.1dbg/lib/liblldb.so
#5 0x00007ffff612fbde in
lldb_private::process_gdb_remote::ProcessGDBRemote::DoAttachToProcessWithID(unsigned
long, lldb_private::ProcessAttachInfo const&) ()
from /tools/llvm/3.7.1dbg/lib/liblldb.so
#6 0x00007ffff623efa5 in
lldb_private::Process::Attach(lldb_private::ProcessAttachInfo&) () from
/tools/llvm/3.7.1dbg/lib/liblldb.so
#7 0x00007ffff7025cc4 in
PlatformPOSIX::Attach(lldb_private::ProcessAttachInfo&,
lldb_private::Debugger&, lldb_private::Target*, lldb_private::Error&) ()
from /tools/llvm/3.7.1dbg/lib/liblldb.so
#8 0x00007ffff626ef52 in
lldb_private::Target::Attach(lldb_private::ProcessAttachInfo&,
lldb_private::Stream*) () from /tools/llvm/3.7.1dbg/lib/liblldb.so
#9 0x00007ffff5d4a4d7 in (anonymous
namespace)::AttachToProcess(lldb_private::ProcessAttachInfo&,
lldb_private::Target&) ()
from /tools/llvm/3.7.1dbg/lib/liblldb.so
#10 0x00007ffff5d4a149 in lldb::SBTarget::Attach(lldb::SBAttachInfo&,
lldb::SBError&) () from /tools/llvm/3.7.1dbg/lib/liblldb.so
Target is Ubuntu LTS 14.04 on x86_64.
Has anything changed in the API over the past year? It looks like LLDB is
creating a server internally; it is terminating quickly for some reason,
and the LLDB parent is waiting forever for its server.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160108/ae6abd1b/attachment.html>
More information about the lldb-dev
mailing list