<div dir="ltr"><div>Hey Todd, great! I think if we end up in there and it's not a SIGSTOP then we
have no idea what's going on and it's not clear what the correct behaviour
would be. I'm happy to wrap the whole thing in an if statement checking
for SIGSTOP though if you think that's best, though it's not clear whether the thing to do is to continue or return at that point.<br><br></div>Thanks!<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jan 27, 2014 at 6:06 PM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Verified this fixes it. I'll go ahead and check it in.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 27, 2014 at 9:00 AM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm giving this a shot now locally. The change looks reasonable to me - any ptrace experts disagree?<div>
<br></div><div>The one bit I'm not entirely sure about is: if assertions are disabled, and for some reason the WSTOPSIG(status) is not SIGSTOP (since we're not explicitly checking before the Resume(wait_pid, SIGSTOP) call), how badly can that gunk things up? An if check before the Resume call would at least stop the wrong signal from getting sent to the inferior if I'm reading it right.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Mon, Jan 27, 2014 at 2:47 AM, Andrew MacPherson <span dir="ltr"><<a href="mailto:andrew.macp@gmail.com" target="_blank">andrew.macp@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">This patch addresses a bug where in a multi-threaded program a new signal from the inferior may be received before all group-stop messages from an earlier signal have been handled. The attached .cpp file exposes the issue:<br>
<ul><li>clang++ -o thread thread.cpp -lpthread -g -O0<br></li><li>lldb ./thread</li><li>r</li><li>hit Ctrl-C</li><li>br set -f thread.cpp -l 11</li><li>c</li><li><hang></li></ul><p>A breakpoint is usually hit before all the group-stop messages involved in restarting the process are handled and the internal state then gets out of sync.<br>
</p>
<p>The attached patch solves the issue and all unit tests pass, I'm not a ptrace expert though so there may be a more appropriate fix. The group-stop handling was taken from the existing ProcessMonitor::MonitorCallback.<br>
</p><p>Thanks,</p><p>Andrew<br></p><p><br></p></div>
<br></div></div>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table style="color:rgb(136,136,136);font-family:'Times New Roman'" cellpadding="0" cellspacing="0">
<tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px" nowrap>Todd Fiala |</td><td style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px" nowrap> Software Engineer |</td>
<td style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px" nowrap> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td>
<td style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px" nowrap><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table style="color:rgb(136,136,136);font-family:'Times New Roman'" cellpadding="0" cellspacing="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px" nowrap>Todd Fiala |</td><td style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px" nowrap> Software Engineer |</td>
<td style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px" nowrap> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td>
<td style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px" nowrap><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div>
</div></div></blockquote></div><br></div>