<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Ryan,<br>
I made changes to StopInfo recently to add the stack, r238323. I'll
have a closer look at this and see if I can figure out what's going
on. <br>
Thanks for bringing this up. <br>
<br>
Best, <br>
Ewan<br>
<br>
<br>
<div class="moz-cite-prefix">On 01/06/2015 18:09, Ryan Brown wrote:<br>
</div>
<blockquote
cite="mid:CAKVxoBH3Dos21_nV2TbFSVnbno6PTP+OJTZ+Xp7PjZ4YS9-BfQ@mail.gmail.com"
type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>I think I found the other problem.</div>
<div>ProcessGDBRemote now has a stack of stop infos.</div>
<div>RefreshStateAfterStop loops through them and
calls SetThreadStopInfo, which in turn calls
UpdateThreadListIfNecessary.<br>
</div>
<div>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.</div>
<div><br>
</div>
<div>So ignoring the threads for the 2nd stop packet is part of
the problem. But why are there two in the first place?</div>
<div>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.</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature">-- Ryan Brown<br>
</div>
</div>
<br>
<div class="gmail_quote">On Mon, Jun 1, 2015 at 3:35 AM, Pavel
Labath <span dir="ltr"><<a moz-do-not-send="true" href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I'm not really sure what is going on, but I don't think the
problem is<br>
in the server component. The server reports the correct
register<br>
values. You say your plugin does not do anything which
should change<br>
the registers (and the packet log confirms this), so it
looks like the<br>
corruption happens in LLDB. I'm afraid I don't know enough
about the<br>
client to know what is the problem, but it seems like you
are hitting<br>
some kind of a race there. Possibly you are reading the
register<br>
values before they have been populated (possibly even before
the whole<br>
thread list is populated, which could explain why you are
getting<br>
inconsistent thread counts).<br>
<span class=""><br>
On 29 May 2015 at 17:15, Ryan Brown <<a moz-do-not-send="true" href="mailto:ribrdb@google.com">ribrdb@google.com</a>>
wrote:<br>
> It seemed like this is the way to connect to an
already running gdbserver. I<br>
> was trying to see the output of gdb server to see why
it was crashing.<br>
> Although I suppose the "OS or CPU not supported!"
message might just mean I<br>
> started lldb-server with the wrong args and not the
real problem.<br>
</span>Yeah, debugging the server is not very easy. I
usually just attach to<br>
a running instance, or load the resulting core file. As I
said, this<br>
looks like a client issue, but it should still not crash the
server.<br>
If you encounter a server crash (without using "process
connect"), I<br>
would be interested in it and can probably fix it.<br>
<span class=""><br>
<br>
> Here's a log from one session:<br>
><br>
<br>
</span><snip><br>
<span class=""><br>
> < 588> read packet:<br>
>
$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<br>
</span>This is the packet notifying the client you've hit a
breakpoint. It<br>
also provides the values of the general purpose registers.
The values<br>
seem reasonable here.<br>
After this, you are only doing memory read commands, and
these should<br>
not affect the registers.<br>
<div>
<div class="h5"><br>
<br>
> (lldb) register read<br>
> General Purpose Registers:<br>
> rax = 0x0000000000000000<br>
> rbx = 0x0000000000000000<br>
> rcx = 0x0000000000000000<br>
> rdx = 0x0000000000000000<br>
> rdi = 0x0000000000000000<br>
> rsi = 0x0000000000000000<br>
> rbp = 0x0000000000000000<br>
> rsp = 0x00007fffffffdde0<br>
> r8 = 0x0000000000000000<br>
> r9 = 0x0000000000000000<br>
> r10 = 0x0000000000000000<br>
> r11 = 0x0000000000000000<br>
> r12 = 0x0000000000000000<br>
> r13 = 0x0000000000000000<br>
> r14 = 0x0000000000000000<br>
> r15 = 0x0000000000000000<br>
> rip = 0x00007ffff7ddb2d0<br>
> rflags = 0x0000000000000200<br>
> cs = 0x0000000000000033<br>
> fs = 0x0000000000000000<br>
> gs = 0x0000000000000000<br>
> ss = 0x000000000000002b<br>
> ds = 0x0000000000000000<br>
> es = 0x0000000000000000<br>
</div>
</div>
"register read" does not need to issue any new server
commands, since<br>
it thinks the register values have already been provided.
However, it<br>
seems they got corrupted on their way...<br>
<br>
<br>
hope this helps,<br>
pl<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
lldb-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Ewan Crawford
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: <a class="moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.codeplay.com&d=AwMD-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=DDUMf06MYELAe1Nlv7KChiwJLLHbYha4jtK_AOiWqwQ&m=RgLGEaVXjyGOaOr-DfO8pqGZqJDvYxnRJmn3wCBlbwo&s=kjk99N7d7skV1wXL4eguB_EgKhkmevmSQq0g9WkDeYk&e=">http://www.codeplay.com</a>
Twitter: <a class="moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_codeplaysoft&d=AwMD-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=DDUMf06MYELAe1Nlv7KChiwJLLHbYha4jtK_AOiWqwQ&m=RgLGEaVXjyGOaOr-DfO8pqGZqJDvYxnRJmn3wCBlbwo&s=QEA9DgKU292n3m9D5rtJMspkDNIIaKoutpQjuesBC-Q&e=">https://twitter.com/codeplaysoft</a>
This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY </pre>
</body>
</html>