<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 9:45 AM Pavel Labath <<a href="mailto:pavel@labath.sk">pavel@labath.sk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/12/2018 18:36, Jonas Devlieghere wrote:<br>
> I believe that posix doesn't make this guarantee, but that in reality <br>
> neither linux nor darwin recycles pids before they wrap around?<br>
<br>
Yes, linux tries pretty hard to not recycle pids, but this is hampered <br>
by the fact that the default pid limit  is 32k and that process and <br>
thread ids share the same namespace.<br>
<br>
So given that we have over 1k tests and each test can easily spawn over <br>
32 tids/pids on a 32-core machine (parallel parsing of debug info), we <br>
can easily run through the whole pid pool in a single test run.<br></blockquote><div><br></div><div>Yeah, that makes sense. What I meant is that I don't think it's what's happening here as we're only running a few tests and I can see the pids are moslty consecutive. </div><div><br></div><div>As I mentioned in the previous e-mail I wrote a Python module in C to check who's sending the PID. It turns out it's the inferior, the one that's receiving signal 17 (SIGSTOP) from the debugserver. This actually makes sense as SIGSTOP is involved in process control. I'd have to double check, but it would definitely make sense if this signal is sent to the whole foreground process group, similar to ^C and it would explain why changing that prevents this from happening. </div><div><br></div><div>I'm going to see what happens if I change the SIGSTOP into a SIGINT.</div></div></div>