[lldb-dev] Hang during attach
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;
//SBAttachInfoai(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.
0x72bd566b 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 0x72bd566b in pthread_join (threadid=140737169864448,
thread_return=0x0) at pthread_join.c:92
#1 0x75f8247c in lldb_private::HostThreadPosix::Join(void**) ()
from /tools/llvm/3.7.1dbg/lib/liblldb.so
#2 0x75f7034d in lldb_private::HostThread::Join(void**) ()
from /tools/llvm/3.7.1dbg/lib/liblldb.so
#3 0x7610802e 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 0x7612f5c0 in
lldb_private::process_gdb_remote::ProcessGDBRemote::LaunchAndConnectToDebugserver(lldb_private::ProcessInfo
const&) ()
from /tools/llvm/3.7.1dbg/lib/liblldb.so
#5 0x7612fbde in
lldb_private::process_gdb_remote::ProcessGDBRemote::DoAttachToProcessWithID(unsigned
long, lldb_private::ProcessAttachInfo const&) ()
from /tools/llvm/3.7.1dbg/lib/liblldb.so
#6 0x7623efa5 in
lldb_private::Process::Attach(lldb_private::ProcessAttachInfo&) () from
/tools/llvm/3.7.1dbg/lib/liblldb.so
#7 0x77025cc4 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 0x7626ef52 in
lldb_private::Target::Attach(lldb_private::ProcessAttachInfo&,
lldb_private::Stream*) () from /tools/llvm/3.7.1dbg/lib/liblldb.so
#9 0x75d4a4d7 in (anonymous
namespace)::AttachToProcess(lldb_private::ProcessAttachInfo&,
lldb_private::Target&) ()
from /tools/llvm/3.7.1dbg/lib/liblldb.so
#10 0x75d4a149 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] Does LLDB work on Ubuntu 14.04 x86_64?
I'm trying out the release candidate(?) as follows: svn co http://llvm.org/svn/llvm-project/llvm/branches/release_38 llvm svn co http://llvm.org/svn/llvm-project/cfe/branches/release_38 cfe svn co http://llvm.org/svn/llvm-project/lldb/branches/release_38 lldb cd llvm/tools ln -s ../../cfe clang ln -s ../../lldb lldb cd .. mkdir build cd build cmake -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON -DCMAKE_INSTALL_PREFIX=/tools/llvm/rel_38 -DLLVM_TARGETS_TO_BUILD="X86;CppBackend" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON .. cmake --build . -- -j4 sudo cmake --build . --target install LLVM fundamentally works: I am able to link the LLVM libraries with my application, and my application passes its regression tests. clang fundamentally works: it is able to compile a program. But lldb: dej@slam:~$ export LD_LIBRARY_PATH=/tools/llvm/rel_38/lib dej@slam:~$ export PATH=/tools/llvm/rel_38/bin:$PATH dej@slam:~$ lldb /bin/ls (lldb) target create "/bin/ls" Current executable set to '/bin/ls' (x86_64). (lldb) r Process 13656 launched: '/bin/ls' (x86_64) Segmentation fault (core dumped) dej@slam:~$ gdb lldb core ... (gdb) bt #0 0x7fd9971b5671 in LLVMDisasmInstruction () from /tools/llvm/rel_38/bin/../lib/../lib/libLLVM-3.8.so #1 0x7fd999e350c2 in AssemblyParse_x86::instruction_length(lldb_private::Address, int&) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #2 0x7fd999e37d08 in AssemblyParse_x86::get_non_call_site_unwind_plan(lldb_private::UnwindPlan&) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #3 0x7fd999e38e95 in UnwindAssembly_x86::GetNonCallSiteUnwindPlanFromAssembly(lldb_private::AddressRange&, lldb_private::Thread&, lldb_private::UnwindPlan&) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #4 0x7fd999c8693b in lldb_private::FuncUnwinders::GetAssemblyUnwindPlan(lldb_private::Target&, lldb_private::Thread&, int) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #5 0x7fd999c88594 in lldb_private::FuncUnwinders::GetUnwindPlanAtNonCallSite(lldb_private::Target&, lldb_private::Thread&, int) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #6 0x7fd999dfb16d in lldb_private::RegisterContextLLDB::GetFullUnwindPlanForFrame() () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #7 0x7fd999dfff90 in lldb_private::RegisterContextLLDB::InitializeZerothFrame() () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #8 0x7fd999e01e83 in lldb_private::RegisterContextLLDB::RegisterContextLLDB(lldb_private::Thread&, std::shared_ptr const&, lldb_private::SymbolContext&, unsigned int, lldb_private::UnwindLLDB&) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #9 0x7fd999df5d43 in lldb_private::UnwindLLDB::AddFirstFrame() () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #10 0x7fd999df63d0 in lldb_private::UnwindLLDB::DoGetFrameInfoAtIndex(unsigned int, unsigned long&, unsigned long&) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #11 0x7fd999d1049b in lldb_private::StackFrameList::GetFramesUpTo(unsigned int) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #12 0x7fd999d11a23 in lldb_private::StackFrameList::GetFrameAtIndex(unsigned int) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #13 0x7fd999ce4ae1 in lldb_private::Thread::GetStackFrameAtIndex(unsigned int) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #14 0x7fd999cc839a in lldb_private::StopInfoBreakpoint::ShouldStopSynchronous(lldb_private::Event*) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #15 0x7fd999ce75b3 in lldb_private::Thread::ShouldStop(lldb_private::Event*) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #16 0x7fd999cee452 in lldb_private::ThreadList::ShouldStop(lldb_private::Event*) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #17 0x7fd999cb505b in lldb_private::Process::ShouldBroadcastEvent(lldb_private::Event*) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #18 0x7fd999cb5111 in lldb_private::Process::HandlePrivateEvent(std::shared_ptr&) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #19 0x7fd999cb5f73 in lldb_private::Process::RunPrivateStateThread(bool) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #20 0x7fd999b45d67 in lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0 #21 0x7fd9990e6182 in start_thread (arg=0x7fd990f62700) at pthread_create.c:312 #22 0x7fd9983da47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Is LLDB expected to be working on Linux x64_64? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Bad state of release 3.7.1?
r246756 has a fix, if you are comfortable applying it. It's a large patch. In theory it should back-port but I have not tried it. The API gap from 3.7.1 to 3.8 is quite minimal, so you should be able to get your applications running with 3.8 rather easily if they are running on 3.7.1 already. On Mon, Jan 25, 2016 at 7:40 PM, Jeffrey Tan wrote: > Btw: is there a fix that we can cherry pick? Or is it safe for us to build > lldb 3.8rc1 with llvm3.7.1? > > On Mon, Jan 25, 2016 at 4:34 PM, Jeffrey Tan > wrote: > >> Thanks David. >> I am new to lldb group but it's kind of surprise to me that the lldb on >> the official release page(http://llvm.org/releases/download.html#3.7.1) >> can have such big problems(can't attach/launch). Don't we fully test lldb >> before we post on the official website? >> >> >> >> On Mon, Jan 25, 2016 at 4:12 PM, David Jones >> wrote: >> >>> This is a known problem with 3.7.1. >>> >>> It should be fixed for 3.8. You should be able to try out 3.8rc1 right >>> now. >>> >>> >>> >>> On Mon, Jan 25, 2016 at 5:37 PM, Jeffrey Tan via lldb-dev < >>> lldb-dev@lists.llvm.org> wrote: >>> Hi, My colleague downloaded and built 3.7.1 version of lldb on Linux. When we used it to attach to a normal process(like sleep), it just hangs forever: bin/lldb -n sleep (lldb) process attach --name "sleep" And my private built 3.8.0 version works fine. Just to confirm, is 3.7.1 a bad version? Is there any known issue about it? Thanks ___ 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
[lldb-dev] Hang of LLDB 3.8.0 on Debian 8
I am trying to run LLDB from the 3.8.0 release on a Debian 8 system.
However, LLDB hangs during attach:
$ lldb /bin/ls
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) r
At which point it hangs. From another window:
$ ps -eLf|grep djones
djones 32218 7418 32218 33 10:33 pts/18 00:00:00 lldb /bin/ls
djones 32218 7418 32224 03 10:33 pts/18 00:00:00 lldb /bin/ls
djones 32218 7418 32225 03 10:34 pts/18 00:00:00 lldb /bin/ls
So three threads are created. I'm not sure how far LLDB got in creating its
target.
The 3.7 releases did this, on both Debian and Ubuntu 14.04LTS. However, the
3.8 release fixed this for Ubuntu. I had neglected to test this on Debian.
I am also using LLDB as a library in my own application. Tracing through
that, my app hangs in the call to SBTarget::AttachToProcessWithID.
strace -f provides insight:
[pid 532] write(2, ": CommandLine Error: Option '", 29) = 29
[pid 532] write(2, "debug", 5)= 5
[pid 532] write(2, "' registered more than once!\n", 29) = 29
[pid 532] write(2, "LLVM ERROR: inconsistency in reg"..., 60) = 60
[pid 532] exit_group(1) = ?
[pid 532] +++ exited with 1 +++
[pid 524] <... futex resumed> ) = ? ERESTARTSYS (To be restarted if
SA_RESTART is set)
[pid 533] <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 1}],
__WALL, NULL) = 532
[pid 524] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=532,
si_uid=1500, si_status=1, si_utime=0, si_stime=0} ---
[pid 524] futex(0x7fed965909d0, FUTEX_WAIT, 531, NULL
[pid 533] madvise(0x7fed9558f000, 8368128, MADV_DONTNEED) = 0
[pid 533] _exit(0)= ?
[pid 533] +++ exited with 0 +++
It looks like the error message to the effect that an option was registered
more than once never makes it out, causes child death, and the parent hangs
waiting for a child that will never signal.
LLVM was built as follows:
tar xJf Downloads/llvm-3.8.0.src.tar.xz
tar xJf Downloads/cfe-3.8.0.src.tar.xz
tar xJf Downloads/lldb-3.8.0.src.tar.xz
cd llvm-3.8.0.src/tools
ln -s ../../cfe-3.8.0.src/ clang
ln -s ../../lldb-3.8.0.src/ lldb
cmake -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON
-DCMAKE_INSTALL_PREFIX=/tools/llvm/3.8.0dbg
-DLLVM_TARGETS_TO_BUILD="X86;CppBackend" -DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_ASSERTIONS=ON ..
cmake --build . -- -j4
sudo cmake --build . --target install
Is this a known issue?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Evolution
On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I've sampled the python code from the llvm repository, and it seems to
> be using a mixture of 4-, 2-, and even 8- character indent, with 4
> being the most prevalent. So, I think we can safely stay with status
> quo.
>
>
(Comment from the peanut gallery...)
Python does have a language-level style guide (PEP-8):
https://www.python.org/dev/peps/pep-0008/
If code is going to be reformatted, then it may be best to try to converge
on exactly the PEP-8 style. Speaking as a project "outsider" (i.e., not an
active contributor), but someone with Python background, anything that
diverges from standard Python style seems jarring (at least to me).
> It will take some editor tweaking to make it use the correct indent
> for different files, but it should be manageable.
>
> pl
>
> On 12 August 2016 at 18:13, Jim Ingham wrote:
> >
> >> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
> >> wrote:
> >>> I recommend approaching this in three steps:
> >>>
> >>> 1) get the less-controversial changes done that Greg was outlining.
> >>> 2) start a discussion in the llvm community about the concept of a
> >>> member/global prefix.
> >>> 2a) the community could agree that llvm-as-a-whole should move to
> prefixes
> >>> or otherwise change the camel case policy.
> >>> 2b) the community could agree that the existing policies are preferred
> >>> 3) LLDB moves to whatever is the end result of the discussion.
> >>>
> >>> I guess what I’m saying is that since the opinions about this are very
> >>> strong, and because we haven’t really had that debate in the LLVM
> community,
> >>> that it would be bad to proactively move to the LLVM style, simply to
> have
> >>> to move back later. Iff the (sure to be extensive) community
> discussion
> >>> settles on the idea that prefixes are the wrong thing, then LLDB should
> >>> remove them to be consistent.
> >>>
> >>> -Chris
> >>
> >> +1
> >>
> >>
> >>
> >> In terms of the formatting of tests, I did some more research on this.
> >> I think the changes needed to be made to the test suite are generally
> >> trivial to fix (e.g. r278490), but I don't think we can avoid a manual
> >> intervention. CommentPragmas does not seem to be a silver bullet -- it
> >> does prevent clang-format from breaking the comment, but it does not
> >> prevent it from moving the whole comment to a new line. That said,
> >> when I reformatted the test sources with CommentPragmas set, the
> >> number of failures went down to 80 (from about 150)...
> >>
> >> I believe we should still perform the reformatting of the tests, at
> >> least to standardize on the 2 space indent (in fact we should consider
> >> doing the same for the python code as well, I don't know what's the
> >> situation there in llvm land), but it can be done later. It will make
> >> the period while the code is in flux longer, but hopefully not too
> >> long. Also the modifications will be independent of the main reformat,
> >> so it will still be true that a single source file only got
> >> reformatted once.
> >>
> >
> > My eyes put in a vote for not reformatting the Python to 2 space tabs.
> In C++, most IDE's do smart things with double-clicking on { to find the
> closing ones easing the task that two space indents makes somewhat harder.
> But since the spacing is the only nesting indicator in Python, it would be
> nice to keep that more visually apparent.
> >
> >> pl
> >> ___
> >> 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
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
