[lldb-dev] strange issues on linux

[Ryan Brown]

I can't reproduce the server crash at the moment, but it was crashing
immediately at process launch, so I don't think attaching to it would work.

I think I found the other problem.
ProcessGDBRemote now has a stack of stop infos.
RefreshStateAfterStop loops through them and calls SetThreadStopInfo, which
in turn calls UpdateThreadListIfNecessary.
But what if these stop infos have different thread lists? Which do you
believe? Currently the first update succeeds and then the others seem to be
ignored because the stop info hasn't changed.

So ignoring the threads for the 2nd stop packet is part of the problem. But
why are there two in the first place?
ProcessGDBRemote::DoLaunch calls SetLastStopPacket which pushes the packet
onto the stack. But then it directly calls SetThreadStopInfo, bypassing
RefreshStateAfterStop. So the packet stays on the stack and gets processed
again along with the next stop packet.

-- Ryan Brown

On Mon, Jun 1, 2015 at 3:35 AM, Pavel Labath <labath at google.com> wrote:

> Hello,
>
> I'm not really sure what is going on, but I don't think the problem is
> in the server component. The server reports the correct register
> values. You say your plugin does not do anything which should change
> the registers (and the packet log confirms this), so it looks like the
> corruption happens in LLDB. I'm afraid I don't know enough about the
> client to know what is the problem, but it seems like you are hitting
> some kind of a race there. Possibly you are reading the register
> values before they have been populated (possibly even before the whole
> thread list is populated, which could explain why you are getting
> inconsistent thread counts).
>
> On 29 May 2015 at 17:15, Ryan Brown <ribrdb at google.com> wrote:
> > It seemed like this is the way to connect to an already running
> gdbserver. I
> > was trying to see the output of gdb server to see why it was crashing.
> > Although I suppose the "OS or CPU not supported!" message might just
> mean I
> > started lldb-server with the wrong args and not the real problem.
> Yeah, debugging the server is not very easy. I usually just attach to
> a running instance, or load the resulting core file. As I said, this
> looks like a client issue, but it should still not crash the server.
> If you encounter a server crash (without using "process connect"), I
> would be interested in it and can probably fix it.
>
>
> > Here's a log from one session:
> >
>
> <snip>
>
> > < 588> read packet:
> >
> $T05thread:5cdf;name:vc.test;threads:5cd5,5cdb,5cdc,5cdd,5cde,5cdf,5ce0,5ce1,5ce2,5ce3;00:883e4c08c2000000;01:0000000000000000;02:401a0008c2000000;03:90d3950000000000;04:0000000000000000;05:683f4c08c2000000;06:78d5ab0000000000;07:083e4c08c2000000;08:2e8d685500000000;09:0700000000000000;0a:403d053600000000;0b:7b00000000000000;0c:1100000000000000;0d:7cc4950000000000;0e:0800000000000000;0f:0000000000000000;10:79f1490000000000;11:4602000000000000;12:3300000000000000;13:0000000000000000;14:0000000000000000;15:2b00000000000000;16:0000000000000000;17:0000000000000000;reason:breakpoint;#14
> This is the packet notifying the client you've hit a breakpoint. It
> also provides the values of the general purpose registers. The values
> seem reasonable here.
> After this, you are only doing memory read commands, and these should
> not affect the registers.
>
>
> > (lldb) register read
> > General Purpose Registers:
> >        rax = 0x0000000000000000
> >        rbx = 0x0000000000000000
> >        rcx = 0x0000000000000000
> >        rdx = 0x0000000000000000
> >        rdi = 0x0000000000000000
> >        rsi = 0x0000000000000000
> >        rbp = 0x0000000000000000
> >        rsp = 0x00007fffffffdde0
> >         r8 = 0x0000000000000000
> >         r9 = 0x0000000000000000
> >        r10 = 0x0000000000000000
> >        r11 = 0x0000000000000000
> >        r12 = 0x0000000000000000
> >        r13 = 0x0000000000000000
> >        r14 = 0x0000000000000000
> >        r15 = 0x0000000000000000
> >        rip = 0x00007ffff7ddb2d0
> >     rflags = 0x0000000000000200
> >         cs = 0x0000000000000033
> >         fs = 0x0000000000000000
> >         gs = 0x0000000000000000
> >         ss = 0x000000000000002b
> >         ds = 0x0000000000000000
> >         es = 0x0000000000000000
> "register read" does not need to issue any new server commands, since
> it thinks the register values have already been provided. However, it
> seems they got corrupted on their way...
>
>
> hope this helps,
> pl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150601/eceac860/attachment.html>