<div dir="ltr">Ok that makes sense. I've updated the patch I sent yesterday with a unit test that exposes the problem as well as a couple of other process attach issues that were fixed in the last few days. It was in fact this getpgid() issue that was causing problems when trying to create a unit test earlier as the problem scenario occurs when the unit test script forks a subprocess with popen().<br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 26, 2014 at 7:20 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On Mar 25, 2014, at 12:09 PM, Andrew MacPherson <<a href="mailto:andrew.macp@gmail.com">andrew.macp@gmail.com</a>> wrote:<br>
<br>
> Ok great, I'm attaching a patch here that just uses getpgid() to determine the pgid to use with waitpid(). I get the same unit test results before and after the patch (there are a few tests that fail consistently for me). I tried using a simple -1 with waitpid() but this results in a hang in the unit tests. This is probably something worth investigating but for now this patch does resolve the issues around waitpid() when attaching.<br>


<br>
</div>We should never use -1 with waitpid() as you could end up reaping a process that someone else is already trying to reap. You must only try to reap the process that you launched using some pid for you process. Many things launch processes within LLDB like ProcessGDBRemote launching "debugserver" binaries. The ProcessGDBRemote must be notified when and if "debugserver" crashes, so if anyone else does waitpid(-1, ...) ProcessGDBRemote might never find out if debugserver crashes for some reason.<br>


<div class=""><br>
> I mentioned a few issues I ran into with the unit tests in the email I just pinged with a Linux detach patch, basically there appears to be a bug or limitation somewhere in that doing a "continue" in asynchronous mode in a unit test breaks things and this is needed for most attach-related debug testing. I can probably look into this (along with the couple of failing tests I have) but likely won't be able to this week. I haven't filed a bug for the consistently-failing tests on my end since it doesn't appear to be happening for others and I haven't had a chance to investigate here, let me know if I should file a bug anyway.<br>


><br>
><br>
> On Tue, Mar 25, 2014 at 6:30 PM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
> I'd suggest trying the change, running the tests, and see if anything new fails.<br>
><br>
> And if this fixes currently broken behavior, add a test to make sure we don't regress it.  I'm pretty sure if it breaks something we'll know pretty quickly (either via bugs or our own usage).  At which point - we should add a test so we don't regress in the future and perhaps add a few comments as to the reason.<br>


><br>
><br>
> On Tue, Mar 25, 2014 at 9:54 AM, <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br>
> Why are you waiting for process groups?  That's not something we have to do on Mac OS X.<br>
><br>
> Jim<br>
><br>
><br>
> On Mar 25, 2014, at 1:17 AM, Andrew MacPherson <<a href="mailto:andrew.macp@gmail.com">andrew.macp@gmail.com</a>> wrote:<br>
><br>
> > Currently under Linux if you attach to a process whose process group id is not equal to its process id (such as the child process of a fork() call) the calls to waitpid() that pass -1*pid will return ECHILD since the pid argument refers to a process group that doesn't exist. These calls occur in Host::MonitorChildProcessThreadFunction() and the Linux ProcessMonitor.<br>


> ><br>
> > Changing -1*pid to simply -1 or to -1*getpgid(pid) resolves the issue but it's not clear if this is the right fix as I'm unsure how other OSes deal with this scenario.<br>
> ><br>
> > Any thoughts?<br>
> ><br>
> > Thanks,<br>
> > Andrew<br>
> > _______________________________________________<br>
> > lldb-dev mailing list<br>
> > <a href="mailto:lldb-dev@cs.uiuc.edu">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>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">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>
><br>
><br>
> --<br>
> Todd Fiala |   Software Engineer |     <a href="mailto:tfiala@google.com">tfiala@google.com</a> |     <a href="tel:650-943-3180" value="+16509433180">650-943-3180</a><br>
><br>
><br>
</div>> <waitpid-getpgid.patch>_______________________________________________<br>
<div class="HOEnZb"><div class="h5">> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">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>
</div></div></blockquote></div><br></div>