Re: [lldb-dev] hang bug in lldb-mi -var-update
If that’s the expectation, you have to obey it... Xcode is pretty careful to
only act on the elements that were visible in a view, which made the locals
view much less heavy-weight. But that took some work on their end.
More to the point, this doesn’t seem to be code that should be in the MI layer.
Shouldn’t this be a method on the SBValue? If there was something tricky that
you could get wrong, it would be better to centralize it.
As Greg says, this shouldn’t be the default “has changed” behavior, but still
it seems like it should be an SBValue method.
Jim
> On Aug 25, 2017, at 3:49 PM, Ted Woodward via lldb-dev
> wrote:
>
> The spec says that's what it should do. From
> https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Variable-Objects.html :
>
> "Reevaluate the expressions corresponding to the variable object name and
> all its direct and indirect children, and return the list of variable
> objects whose values have changed;"
>
> Also, our Eclipse guy gets grumpy when it doesn't :-)
>
> Ted
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>> -Original Message-
>> From: Greg Clayton [mailto:clayb...@gmail.com]
>> Sent: Friday, August 25, 2017 5:00 PM
>> To: Ted Woodward
>> Cc: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] hang bug in lldb-mi -var-update
>>
>> lldb-mi should never be checking the children. This is never a good idea
> due to
>> performance. What happens when you have an array with a million entries?
>> Long delay. Aggregate types should never say they changed. Only SBValue
>> objects that have values should claim to change.
>>
>> Greg
>>
>>
>>> On Aug 25, 2017, at 10:42 AM, Ted Woodward via lldb-dev > d...@lists.llvm.org> wrote:
>>>
>>> I found a hang in lldb-mi's -var-update. It checks to see if a var
>>> changed, then it checks each of the children recursively. If a child
>>> is a pointer back to a parent, as in this case:
>>>
>>> struct complex_type
>>> {
>>> int i;
>>> struct { long l; } inner;
>>> struct complex_type *complex_ptr;
>>> };
>>>
>>> void
>>> var_update_test(void)
>>> {
>>> struct complex_type complx_array[2];
>>>
>>> complx_array[0].i = 4;
>>> complx_array[0].inner.l = 4;
>>> complx_array[0].complex_ptr = &complx_array[1];
>>> complx_array[1].i = 5;
>>> complx_array[1].inner.l = 5;
>>> complx_array[1].complex_ptr = &complx_array[0];
>>>
>>>
>>>
>>> the code in CMICmdCmdVarUpdate::ExamineSBValueForChange will get into
>>> an infinite loop.
>>>
>>> const MIuint nChildren = vrwValue.GetNumChildren(); for (MIuint i =
>>> 0; i < nChildren; ++i) {
>>> lldb::SBValue member = vrwValue.GetChildAtIndex(i);
>>> if (!member.IsValid())
>>> continue;
>>>
>>> if (member.GetValueDidChange()) {
>>> vrwbChanged = true;
>>> return MIstatus::success;
>>> } else if (ExamineSBValueForChange(member, vrwbChanged) &&
>> vrwbChanged)
>>> // Handle composite types (i.e. struct or arrays)
>>> return MIstatus::success;
>>> }
>>>
>>> I've got a patch that disables checking a pointer's children. I'll put
>>> it up on phabricator today.
>>>
>>> Ted
>>>
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>>
>>>
>>> ___
>>> 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
[lldb-dev] [5.0.0 Release] Release Candidate 3 tagged
Dear testers, 5.0.0-rc3 was just tagged. This is a release candidate in the real sense: if nothing bad comes up in testing, this is what the release is going to look like. Please build, test and upload binaries to the sftp (use the /data/testers-uploads/ directory) and let me know what issues remain. I know we're a little bit behind schedule, but hopefully we can get to 'final' soon. Cheers, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] hang bug in lldb-mi -var-update
The spec says that's what it should do. From
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Variable-Objects.html :
"Reevaluate the expressions corresponding to the variable object name and
all its direct and indirect children, and return the list of variable
objects whose values have changed;"
Also, our Eclipse guy gets grumpy when it doesn't :-)
Ted
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
> -Original Message-
> From: Greg Clayton [mailto:clayb...@gmail.com]
> Sent: Friday, August 25, 2017 5:00 PM
> To: Ted Woodward
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] hang bug in lldb-mi -var-update
>
> lldb-mi should never be checking the children. This is never a good idea
due to
> performance. What happens when you have an array with a million entries?
> Long delay. Aggregate types should never say they changed. Only SBValue
> objects that have values should claim to change.
>
> Greg
>
>
> > On Aug 25, 2017, at 10:42 AM, Ted Woodward via lldb-dev d...@lists.llvm.org> wrote:
> >
> > I found a hang in lldb-mi's -var-update. It checks to see if a var
> > changed, then it checks each of the children recursively. If a child
> > is a pointer back to a parent, as in this case:
> >
> > struct complex_type
> > {
> >int i;
> >struct { long l; } inner;
> >struct complex_type *complex_ptr;
> > };
> >
> > void
> > var_update_test(void)
> > {
> >struct complex_type complx_array[2];
> >
> >complx_array[0].i = 4;
> >complx_array[0].inner.l = 4;
> >complx_array[0].complex_ptr = &complx_array[1];
> >complx_array[1].i = 5;
> >complx_array[1].inner.l = 5;
> >complx_array[1].complex_ptr = &complx_array[0];
> >
> >
> >
> > the code in CMICmdCmdVarUpdate::ExamineSBValueForChange will get into
> > an infinite loop.
> >
> > const MIuint nChildren = vrwValue.GetNumChildren(); for (MIuint i =
> > 0; i < nChildren; ++i) {
> >lldb::SBValue member = vrwValue.GetChildAtIndex(i);
> >if (!member.IsValid())
> > continue;
> >
> >if (member.GetValueDidChange()) {
> > vrwbChanged = true;
> > return MIstatus::success;
> >} else if (ExamineSBValueForChange(member, vrwbChanged) &&
> vrwbChanged)
> > // Handle composite types (i.e. struct or arrays)
> > return MIstatus::success;
> > }
> >
> > I've got a patch that disables checking a pointer's children. I'll put
> > it up on phabricator today.
> >
> > Ted
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> >
> > ___
> > 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
Re: [lldb-dev] hang bug in lldb-mi -var-update
lldb-mi should never be checking the children. This is never a good idea due to
performance. What happens when you have an array with a million entries? Long
delay. Aggregate types should never say they changed. Only SBValue objects that
have values should claim to change.
Greg
> On Aug 25, 2017, at 10:42 AM, Ted Woodward via lldb-dev
> wrote:
>
> I found a hang in lldb-mi's -var-update. It checks to see if a var changed,
> then it checks each of the children recursively. If a child is a pointer
> back to a parent, as in this case:
>
> struct complex_type
> {
>int i;
>struct { long l; } inner;
>struct complex_type *complex_ptr;
> };
>
> void
> var_update_test(void)
> {
>struct complex_type complx_array[2];
>
>complx_array[0].i = 4;
>complx_array[0].inner.l = 4;
>complx_array[0].complex_ptr = &complx_array[1];
>complx_array[1].i = 5;
>complx_array[1].inner.l = 5;
>complx_array[1].complex_ptr = &complx_array[0];
>
>
>
> the code in CMICmdCmdVarUpdate::ExamineSBValueForChange will get into an
> infinite loop.
>
> const MIuint nChildren = vrwValue.GetNumChildren();
> for (MIuint i = 0; i < nChildren; ++i) {
>lldb::SBValue member = vrwValue.GetChildAtIndex(i);
>if (!member.IsValid())
> continue;
>
>if (member.GetValueDidChange()) {
> vrwbChanged = true;
> return MIstatus::success;
>} else if (ExamineSBValueForChange(member, vrwbChanged) && vrwbChanged)
> // Handle composite types (i.e. struct or arrays)
> return MIstatus::success;
> }
>
> I've got a patch that disables checking a pointer's children. I'll put it up
> on phabricator today.
>
> Ted
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
> ___
> 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
Re: [lldb-dev] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged
> -Original Message- > From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf > Of Hans Wennborg > Sent: 24 August 2017 22:50 > To: Simon Dardis > Cc: Release-testers; llvm-dev; cfe-dev; openmp-dev (openmp- > d...@lists.llvm.org); LLDB Dev > Subject: Re: [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged > > On Tue, Aug 1, 2017 at 3:01 AM, Simon Dardis > wrote: > > Hi all, > > > > I have new regressions for mips(el)-linux-gnu, some of which I have > patches for: > > > > I have patch for (believe this to be a libc bug): > > LLVM-Unit :: > DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfV > erifyInvalidCURef > > LLVM-Unit :: > DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfV > erifyInvalidLineFileIndex > > LLVM-Unit :: > DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfV > erifyInvalidLineSequence > > LLVM-Unit :: > > > DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfV > erifyIn > > validStmtList This appears to be a known regression (PR32910): > > Builtins-mips64-linux :: divtc3_test.c New, investigating: > > Clang :: Index/IBOutletCollection.m > > Clang :: Index/TestClassDecl.m > > Clang :: Index/TestClassForwardDecl.m > > Clang :: Index/allow-editor-placeholders.cpp > > Clang :: Index/annotate-attribute.cpp > > Clang :: Index/annotate-comments-availability-attrs.cpp > > Clang :: Index/annotate-comments-objc.m > > Clang :: Index/annotate-comments-property-accessor.m > > Clang :: Index/annotate-comments-typedef.m > > Clang :: Index/annotate-comments-unterminated.c > > Clang :: Index/annotate-comments.cpp > > Clang :: Index/annotate-context-sensitive.cpp > > Clang :: Index/annotate-deep-statements.cpp > > Clang :: Index/annotate-literals.m > > Clang :: Index/annotate-macro-args.m > > Clang :: Index/annotate-module.m > > Clang :: Index/annotate-nested-name-specifier.cpp > > Clang :: Index/annotate-parameterized-classes.m > > Clang :: Index/annotate-subscripting.m > > Clang :: Index/annotate-tokens-cxx0x.cpp > > Clang :: Index/annotate-tokens-include.c > > Clang :: Index/annotate-tokens-pp.c > > Clang :: Index/annotate-tokens-preamble.c > > Clang :: Index/annotate-tokens-with-default-args.cpp > > Clang :: Index/annotate-tokens.c > > Clang :: Index/annotate-tokens.cpp > > Clang :: Index/annotate-tokens.m > > Clang :: Index/annotate-toplevel-in-objccontainer.m > > Clang :: Index/arc-annotate.m > > Clang :: Index/asm-attribute.c > > Clang :: Index/attributes-cuda.cu > > Clang :: Index/attributes.c > > Clang :: Index/availability.c > > Clang :: Index/availability.cpp > > Clang :: Index/blocks.c > > Clang :: Index/boxed-exprs.m > > Clang :: Index/c-index-api-loadTU-test.m > > Clang :: Index/c-index-getCursor-pp.c > > Clang :: Index/c-index-getCursor-test.m > > Clang :: Index/c-index-pch.c > > Clang :: Index/c-index-redecls.c > > Clang :: Index/cindex-from-source.m > > Clang :: Index/cindex-on-invalid.m > > Clang :: Index/comment-c-decls.c > > Clang :: Index/comment-cplus-decls.cpp > > Clang :: Index/comment-cplus-template-decls.cpp > > Clang :: Index/comment-cplus11-specific.cpp > > Clang :: Index/comment-custom-block-command.cpp > > Clang :: Index/comment-lots-of-unknown-commands.c > > Clang :: Index/comment-misc-tags.m > > Clang :: Index/comment-objc-decls.m > > Clang :: Index/comment-objc-parameterized-classes.m > > Clang :: Index/comment-to-html-xml-conversion.cpp > > Clang :: Index/comment-unqualified-objc-pointer.m > > Clang :: Index/comment-with-preamble.c > > Clang :: Index/complete-module-undef.m > > Clang :: Index/crash-recovery-modules.m > > Clang :: Index/ctor-init-source-loc.cpp > > Clang :: Index/cursor-ref-names.cpp > > Clang :: Index/cxx11-lambdas.cpp > > Clang :: Index/evaluate-cursor.cpp > > Clang :: Index/file-includes.c > > Clang :: Index/file-macro-refs.c > > Clang :: Index/file-refs-subscripting.m > > Clang :: Index/file-refs.c > > Clang :: Index/file-refs.cpp > > Clang :: Index/file-refs.m > > Clang :: Index/fix-its.c > > Clang :: Index/fix-its.m > > Clang :: Index/format-comment-cdecls.c > > Clang :: Index/get-cursor-includes.c > > Clang :: Index/get-cursor.c > > Clang :: Index/get-cursor.cpp > > Clang :: Index/get-cursor.m > > Clang :: Index/getcursor-pp-pch.c > > Clang :: Index/getcursor-preamble.m > > Clang :: Index/headerfile-comment-to-html.m > > Clang :: Index/in-class-init.cpp > > Clang :: Index/index-attrs.c > > Clang :: Index/index-attrs.cpp > > Clang :: Index/index-attrs.m > > Clang :: Index/index-decls.m > > Clang :: Index/index-file.cpp > > Clang :: Index/index-file.cu > > Clang :: Index/index-invalid-code.m > > Clang :: Index/index-kernel-in
Re: [lldb-dev] [llvm-dev] [5.0.0 Release] Only 3 release blockers left, please help fix!
> -Original Message- > From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Hans > Wennborg via llvm-dev > Sent: Thursday, August 24, 2017 6:06 PM > To: llvm-dev; cfe-dev; LLDB Dev; openmp-dev (openmp-...@lists.llvm.org) > Subject: [llvm-dev] [5.0.0 Release] Only 3 release blockers left, please > help fix! > > Hello everyone, > > We started the week with 32 open release blockers and are now down to only > 3: > https://bugs.llvm.org/buglist.cgi?f1=blocked&o1=equals&v1=33849&query_form > at=advanced&resolution=--- > Many thanks for your hard work so far. > > None of the three remaining ones have any traction, so any help would > be much appreciated: > > https://llvm.org/pr33668 > "Excessive memory and CPU use in tail duplication and associated > passes due to critical edge splitting" > Sounds like someone familiar with taildup is needed. > > https://llvm.org/pr33930 > "Assertion `OpN.isUniqued() && "Only uniqued operands cannot be mapped > immediately"' failed." > Needs someone familiar with debug info. See https://reviews.llvm.org/D37038 and comments from Adrian Prantl. I hope to have time to look at this today, but can't guarantee results. --paulr > > https://llvm.org/pr33507 > "Assertion failed: Shift >= 0, file > C:\src\llvm_package_303050\llvm\tools\clang\lib\Format\WhitespaceManager.c > pp, > line 245" > clang-format asserts and breaks the correctness of some code. This > seems bad. Needs someone familiar with clang-format. > > If we can get these squashed, I'll be a very happy release manger. > > Thanks, > Hans > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] hang bug in lldb-mi -var-update
I found a hang in lldb-mi's -var-update. It checks to see if a var changed,
then it checks each of the children recursively. If a child is a pointer
back to a parent, as in this case:
struct complex_type
{
int i;
struct { long l; } inner;
struct complex_type *complex_ptr;
};
void
var_update_test(void)
{
struct complex_type complx_array[2];
complx_array[0].i = 4;
complx_array[0].inner.l = 4;
complx_array[0].complex_ptr = &complx_array[1];
complx_array[1].i = 5;
complx_array[1].inner.l = 5;
complx_array[1].complex_ptr = &complx_array[0];
the code in CMICmdCmdVarUpdate::ExamineSBValueForChange will get into an
infinite loop.
const MIuint nChildren = vrwValue.GetNumChildren();
for (MIuint i = 0; i < nChildren; ++i) {
lldb::SBValue member = vrwValue.GetChildAtIndex(i);
if (!member.IsValid())
continue;
if (member.GetValueDidChange()) {
vrwbChanged = true;
return MIstatus::success;
} else if (ExamineSBValueForChange(member, vrwbChanged) && vrwbChanged)
// Handle composite types (i.e. struct or arrays)
return MIstatus::success;
}
I've got a patch that disables checking a pointer's children. I'll put it up
on phabricator today.
Ted
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Remote debugging ARM target from x86 host
Maybe we can make it open only an IPv4 socket for lldb-server for now as a work
around?
> On Aug 25, 2017, at 8:47 AM, Chris Bieneman wrote:
>
> Since lldb-server only supports running on a limited set of host operating
> systems it is hard for me to diagnose the issue completely, but I suspect the
> problem is caused by the fact that the new listening code can open more than
> one socket, and TCPSocket::GetLocalPortNumber() may be misbehaving.
>
> I'm unlikely to have time to investigate further until next week, but it
> should be possible to craft a unit test that verifies that
> GetLocalPortNumber() returns non-zero on a socket that is listening before a
> connection is established. That might reproduce the issue in a more easy to
> debug environment.
>
> -Chris
>
>> On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev
>> wrote:
>>
>> Ted, Greg,
>>
>> I have built lldb tools @r300578 and the lldb-server is returning the
>> proper port number to lldb client and the remote debugging is working.
>> I have given the lldb-server log at the bottom of my reply.
>>
>> So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
>> support IPv6 over TCP) is causing the issue.
>>
>>> Ramana, can you stick in a log message to print port_cstr? I suspect it's
>>> actually getting 0 back from lldb-server, which would tell us the error is
>>> in the server code, not the client code.
>>
>> Ted, I did that and actually the pipe read is returning zero port
>> number. So definitely the issue is on the server side.
>>
>>GDBRemoteCommunication::StartDebugserverProcess() port_cstr
>> before socket pipe read
>>GDBRemoteCommunication::StartDebugserverProcess() port_cstr after
>> socket pipe read
>>
>>
>>> Ted's comments are correct and I am guessing we will find the "lldb-server
>>> gdb-server" is not doing the right thing and it isn't returning the
>>> correctly bound port.
>>>
>>> When we are doing remote stuff we must use TCP so there should be
>>> lldb-server should be opening a TCP socket, binding, listening and
>>> accepting a connection from the remote LLDB.
>>>
>>> Greg
>>
>> Greg, thanks for the comments. Are you saying I should check what is
>> happening on the TCP socket side? How do I do it other than walking
>> through the code?
>>
>>
>> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb-server platform
>> --log-file Ramana/remote.log --log-channels "gdb-remote process"
>> --server --listen *:1400
>> Connection established.
>> error: lost connection
>> lldb-server exiting...
>> ^C
>> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb --version
>> lldb version 5.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
>> revision 300578)
>> clang revision 300578
>> llvm revision 300578
>> root@arria5:~# cat Ramana/remote.log
>> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0,
>> port=0)
>> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
>> stub exe '/mnt/var/patch_bins/binaries/bin/lldb-server'
>> launch info for gdb-remote stub:
>> Executable: lldb-server
>> Triple: *-*-*
>> Arguments:
>> argv[0]="/mnt/var/patch_bins/binaries/bin/lldb-server"
>> argv[1]="gdbserver"
>> argv[2]="tcp://10.10.12.3:0"
>> argv[3]="--native-regs"
>> argv[4]="--pipe"
>> argv[5]="7"
>> argv[6]=NULL
>>
>> Environment:
>> env[0]="XDG_SESSION_ID=c7"
>> env[1]="TERM=xterm-256color"
>> env[2]="SHELL=/bin/sh"
>> env[3]="SSH_CLIENT=172.16.16.51 40072 22"
>> env[4]="SSH_TTY=/dev/pts/0"
>> env[5]="USER=root"
>> env[6]="MAIL=/var/mail/root"
>> env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
>> env[8]="PWD=/home/root"
>> env[9]="EDITOR=vi"
>> env[10]="PS1=\u@\h:\w\$ "
>> env[11]="SHLVL=1"
>> env[12]="HOME=/home/root"
>> env[13]="LOGNAME=root"
>> env[14]="SSH_CONNECTION=172.16.16.51 40072 10.10.2.4 22"
>> env[15]="XDG_RUNTIME_DIR=/run/user/0"
>> env[16]="_=/mnt/var/patch_bins/binaries/bin/lldb-server"
>> env[17]=NULL
>>
>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 48039
>> port
>>
>>
>> Regards,
>> Ramana
>>
>> On Thu, Aug 24, 2017 at 10:10 PM, Greg Clayton wrote:
>>>
On Aug 24, 2017, at 8:33 AM, Ted Woodward
wrote:
The lldb-server launch line looks ok; it should take the port 0 arg and
get a port from the OS.
lldb is getting the port back from lldb-server in 4.0.1, as seen here:
> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens
> 56543 port
But for 5.0.0 we see it fail the debugserver launch, and get:
> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0
> port
That log message comes right after the pipe read, which succeeds because
error.Success() is true:
// Read port from pipe with 10 second timeout.
error = socket_pipe.ReadWithTimeout(
port_cstr, num_bytes, std::chrono::seconds{10}, num_bytes);
if (error.Success() && (p
Re: [lldb-dev] [Release-testers] [5.0.0 Release] Release Candidate 2 tagged
On 24 Aug 2017, at 23:48, Hans Wennborg wrote: > > On Mon, Aug 14, 2017 at 3:36 AM, Dimitry Andric wrote: >> On 11 Aug 2017, at 04:00, Hans Wennborg via Release-testers >> wrote: >>> 5.0.0-rc2 was just tagged. >>> >>> I know we still have a bunch of open release blockers, but there has >>> been a lot of merged patches and I'd like to find out what the status >>> is. >> >> As in the last rc, most of the ASan tests failed with either: >> >> [ DEATH ] ==5754==AddressSanitizer CHECK failed: >> /home/dim/llvm-5.0.0/rc2/llvm.src/projects/compiler-rt/lib/asan/asan_errors.h:99 >> "((second_free_stack->size)) > ((0))" (0x0, 0x0) >> >> or: >> >> [ DEATH ] ==7514==AddressSanitizer CHECK failed: >> /home/dim/llvm-5.0.0/rc2/llvm.src/projects/compiler-rt/lib/asan/asan_descriptions.cc:176 >> "((id)) != (0)" (0x0, 0x0) >> >> This is likely due to r305058, as mentioned in my report for rc1. > > Was there ever any progress on this, or at least a bug report filed? No progress, but I just filed https://bugs.llvm.org/show_bug.cgi?id=34324 so it hopefully won't get lost. > Do you think it's just the tests that are failing, or does it mean > ASan is broken on FreeBSD? How severe is this issue from your > perspective? It looks like the tests are failing, but simple programs compiled with -fsanitize=address seem to work. I haven't tested it extensively, though. I'm not completely happy with the situation, as we also have some major problems with AddressSanitizer on FreeBSD 12.0 (though this isn't the fault of compiler-rt). But there's no need to block the release for this. -Dimitry signature.asc Description: Message signed with OpenPGP ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Remote debugging ARM target from x86 host
Since lldb-server only supports running on a limited set of host operating
systems it is hard for me to diagnose the issue completely, but I suspect the
problem is caused by the fact that the new listening code can open more than
one socket, and TCPSocket::GetLocalPortNumber() may be misbehaving.
I'm unlikely to have time to investigate further until next week, but it should
be possible to craft a unit test that verifies that GetLocalPortNumber()
returns non-zero on a socket that is listening before a connection is
established. That might reproduce the issue in a more easy to debug environment.
-Chris
> On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev
> wrote:
>
> Ted, Greg,
>
> I have built lldb tools @r300578 and the lldb-server is returning the
> proper port number to lldb client and the remote debugging is working.
> I have given the lldb-server log at the bottom of my reply.
>
> So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
> support IPv6 over TCP) is causing the issue.
>
>> Ramana, can you stick in a log message to print port_cstr? I suspect it's
>> actually getting 0 back from lldb-server, which would tell us the error is
>> in the server code, not the client code.
>
> Ted, I did that and actually the pipe read is returning zero port
> number. So definitely the issue is on the server side.
>
> GDBRemoteCommunication::StartDebugserverProcess() port_cstr
> before socket pipe read
> GDBRemoteCommunication::StartDebugserverProcess() port_cstr after
> socket pipe read
>
>
>> Ted's comments are correct and I am guessing we will find the "lldb-server
>> gdb-server" is not doing the right thing and it isn't returning the
>> correctly bound port.
>>
>> When we are doing remote stuff we must use TCP so there should be
>> lldb-server should be opening a TCP socket, binding, listening and accepting
>> a connection from the remote LLDB.
>>
>> Greg
>
> Greg, thanks for the comments. Are you saying I should check what is
> happening on the TCP socket side? How do I do it other than walking
> through the code?
>
>
> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb-server platform
> --log-file Ramana/remote.log --log-channels "gdb-remote process"
> --server --listen *:1400
> Connection established.
> error: lost connection
> lldb-server exiting...
> ^C
> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb --version
> lldb version 5.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
> revision 300578)
> clang revision 300578
> llvm revision 300578
> root@arria5:~# cat Ramana/remote.log
> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0,
> port=0)
> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
> stub exe '/mnt/var/patch_bins/binaries/bin/lldb-server'
> launch info for gdb-remote stub:
> Executable: lldb-server
> Triple: *-*-*
> Arguments:
> argv[0]="/mnt/var/patch_bins/binaries/bin/lldb-server"
> argv[1]="gdbserver"
> argv[2]="tcp://10.10.12.3:0"
> argv[3]="--native-regs"
> argv[4]="--pipe"
> argv[5]="7"
> argv[6]=NULL
>
> Environment:
> env[0]="XDG_SESSION_ID=c7"
> env[1]="TERM=xterm-256color"
> env[2]="SHELL=/bin/sh"
> env[3]="SSH_CLIENT=172.16.16.51 40072 22"
> env[4]="SSH_TTY=/dev/pts/0"
> env[5]="USER=root"
> env[6]="MAIL=/var/mail/root"
> env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
> env[8]="PWD=/home/root"
> env[9]="EDITOR=vi"
> env[10]="PS1=\u@\h:\w\$ "
> env[11]="SHLVL=1"
> env[12]="HOME=/home/root"
> env[13]="LOGNAME=root"
> env[14]="SSH_CONNECTION=172.16.16.51 40072 10.10.2.4 22"
> env[15]="XDG_RUNTIME_DIR=/run/user/0"
> env[16]="_=/mnt/var/patch_bins/binaries/bin/lldb-server"
> env[17]=NULL
>
> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 48039
> port
>
>
> Regards,
> Ramana
>
> On Thu, Aug 24, 2017 at 10:10 PM, Greg Clayton wrote:
>>
>>> On Aug 24, 2017, at 8:33 AM, Ted Woodward
>>> wrote:
>>>
>>> The lldb-server launch line looks ok; it should take the port 0 arg and get
>>> a port from the OS.
>>> lldb is getting the port back from lldb-server in 4.0.1, as seen here:
>>>
GDBRemoteCommunication::StartDebugserverProcess() debugserver listens
56543 port
>>>
>>> But for 5.0.0 we see it fail the debugserver launch, and get:
>>>
GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0
port
>>>
>>> That log message comes right after the pipe read, which succeeds because
>>> error.Success() is true:
>>>
>>> // Read port from pipe with 10 second timeout.
>>> error = socket_pipe.ReadWithTimeout(
>>> port_cstr, num_bytes, std::chrono::seconds{10}, num_bytes);
>>> if (error.Success() && (port != nullptr)) {
>>> assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');
>>> uint16_t child_port = StringConvert::ToUInt32(port_cstr, 0);
>>> if (*port == 0 || *port == child_port) {
>>> *port = child_port;
>>> if (log)
>>>
Re: [lldb-dev] Remote debugging ARM target from x86 host
Ted, Greg,
I have built lldb tools @r300578 and the lldb-server is returning the
proper port number to lldb client and the remote debugging is working.
I have given the lldb-server log at the bottom of my reply.
So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
support IPv6 over TCP) is causing the issue.
> Ramana, can you stick in a log message to print port_cstr? I suspect it's
> actually getting 0 back from lldb-server, which would tell us the error is in
> the server code, not the client code.
Ted, I did that and actually the pipe read is returning zero port
number. So definitely the issue is on the server side.
GDBRemoteCommunication::StartDebugserverProcess() port_cstr
before socket pipe read
GDBRemoteCommunication::StartDebugserverProcess() port_cstr after
socket pipe read
> Ted's comments are correct and I am guessing we will find the "lldb-server
> gdb-server" is not doing the right thing and it isn't returning the correctly
> bound port.
>
> When we are doing remote stuff we must use TCP so there should be lldb-server
> should be opening a TCP socket, binding, listening and accepting a connection
> from the remote LLDB.
>
> Greg
Greg, thanks for the comments. Are you saying I should check what is
happening on the TCP socket side? How do I do it other than walking
through the code?
root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb-server platform
--log-file Ramana/remote.log --log-channels "gdb-remote process"
--server --listen *:1400
Connection established.
error: lost connection
lldb-server exiting...
^C
root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb --version
lldb version 5.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
revision 300578)
clang revision 300578
llvm revision 300578
root@arria5:~# cat Ramana/remote.log
GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, port=0)
GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
stub exe '/mnt/var/patch_bins/binaries/bin/lldb-server'
launch info for gdb-remote stub:
Executable: lldb-server
Triple: *-*-*
Arguments:
argv[0]="/mnt/var/patch_bins/binaries/bin/lldb-server"
argv[1]="gdbserver"
argv[2]="tcp://10.10.12.3:0"
argv[3]="--native-regs"
argv[4]="--pipe"
argv[5]="7"
argv[6]=NULL
Environment:
env[0]="XDG_SESSION_ID=c7"
env[1]="TERM=xterm-256color"
env[2]="SHELL=/bin/sh"
env[3]="SSH_CLIENT=172.16.16.51 40072 22"
env[4]="SSH_TTY=/dev/pts/0"
env[5]="USER=root"
env[6]="MAIL=/var/mail/root"
env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
env[8]="PWD=/home/root"
env[9]="EDITOR=vi"
env[10]="PS1=\u@\h:\w\$ "
env[11]="SHLVL=1"
env[12]="HOME=/home/root"
env[13]="LOGNAME=root"
env[14]="SSH_CONNECTION=172.16.16.51 40072 10.10.2.4 22"
env[15]="XDG_RUNTIME_DIR=/run/user/0"
env[16]="_=/mnt/var/patch_bins/binaries/bin/lldb-server"
env[17]=NULL
GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 48039 port
Regards,
Ramana
On Thu, Aug 24, 2017 at 10:10 PM, Greg Clayton wrote:
>
>> On Aug 24, 2017, at 8:33 AM, Ted Woodward
>> wrote:
>>
>> The lldb-server launch line looks ok; it should take the port 0 arg and get
>> a port from the OS.
>> lldb is getting the port back from lldb-server in 4.0.1, as seen here:
>>
>>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 56543
>>> port
>>
>> But for 5.0.0 we see it fail the debugserver launch, and get:
>>
>>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0 port
>>
>> That log message comes right after the pipe read, which succeeds because
>> error.Success() is true:
>>
>>// Read port from pipe with 10 second timeout.
>>error = socket_pipe.ReadWithTimeout(
>>port_cstr, num_bytes, std::chrono::seconds{10}, num_bytes);
>>if (error.Success() && (port != nullptr)) {
>> assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');
>> uint16_t child_port = StringConvert::ToUInt32(port_cstr, 0);
>> if (*port == 0 || *port == child_port) {
>>*port = child_port;
>>if (log)
>> log->Printf("GDBRemoteCommunication::%s() "
>> "debugserver listens %u port",
>> __FUNCTION__, *port);
>>
>> As an aside, I don't like that assert - if we get garbage back from the
>> pipe, we should error out, not take down lldb.
>
> The assert should be removed and the code should work correctly without the
> assert.
>
>> Another aside, the definition of port_cstr is odd:
>>char port_cstr[PATH_MAX] = {0};
>>port_cstr[0] = '\0';
>> The size is way to big - max port number is 65535, so we don't need PATH_MAX
>> bytes. And 2 assignments to make it a null string?
>>
>>
>> Ramana, can you stick in a log message to print port_cstr? I suspect it's
>> actually getting 0 back from lldb-server, which would tell us the error is
>> in the server code, not the client code.
>>
>
> With the following args:
>
> argv[0]
