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 <rib...@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 _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
