<div><div dir="auto"><br></div></div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 4, 2018 at 19:11 Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Have you tried an strace to see if it tells you who is sending the signal?</blockquote><div dir="auto"><br></div><div dir="auto">I used DTrace with the default kill.d script. It shows who sends what signal and there was nothing interesting other than debugserver sending signal 17 (SIGSTOP) to the inferior. This makes me think that the signal might be coming from the kernel?</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 4, 2018 at 6:49 PM Jonas Devlieghere via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
Since we switched to lit as the test driver we've been seeing it getting killed as the result of a SIGHUP signal. The problem doesn't reproduce on every machine and there seems to be a correlation between number of occurrences and thread count. <br>
<br>
Davide and Raphael spent some time narrowing down what particular test is causing this and it seems that TestChangeProcessGroup.py is always involved. However it never reproduces when running just this test. I was able to reproduce pretty consistently with the following filter:<br>
<br>
./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ --filter="process"<br>
<br>
Bisecting the test itself didn't help much, the problem reproduces as soon as we attach to the inferior. <br>
<br>
At this point it is still not clear who is sending the SIGHUP and why it's reaching the lit test driver. Fred suggested that it might have something to do with process groups (which would be an interesting coincidence given the previously mentioned test) and he suggested having the test run in different process groups. Indeed, adding a call to os.setpgrp() in lit's executeCommand and having a different process group per test prevent us from seeing this. Regardless of this issue I think it's reasonable to have tests run in their process group, so if nobody objects I propose adding this to lit in llvm. <br>
<br>
Still, I'd like to understand where the signal is coming from and fix the root cause in addition to the symptom. Maybe someone here has an idea of what might be going on? <br>
<br>
Thanks,<br>
Jonas<br>
<br>
PS<br>
<br>
1. There's two places where we send a SIGHUP ourself, with that code removed we still receive the signal, which suggests that it might be coming from Python or the OS.  <br>
2. If you're able to reproduce you'll see that adding an early return before the attach in TestChangeProcessGroup.py hides/prevents the problem. Moving the return down one line and it pops up again. <br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Sent from my iPhone</div>