Also including the list...
On 11 January 2016 at 09:30, Pavel Labath <lab...@google.com> wrote:
> Hi,
>
> there was a race condition in 3.7, which sometimes caused a hang
> during process attach. This should be fixed in r246756, but this fix
> is not available in the 3.7 branch. I think if you try this with the
> current trunk, you should not experience this problem anymore. If you
> still notice the problem with the trunk lldb, then please let me know.
>
>> 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.
> LLDB now spawns a server which performs the actual debugging work
> (which means you can now debug remotely as well), but that should not
> affect the API in any noticeable way.
>
> cheers,
> pl
>
>
> On 9 January 2016 at 01:42, David Jones via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
>> 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.
>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
