<p dir="ltr">I think you should look at git blame on relevant lines in the kernel and ask for help from those people and/or loop them onto this thread.</p>
<div class="gmail_quote">On Mar 19, 2015 8:53 AM, "Pavel Labath" <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">After a considerate amount of effort, I have managed to get a log trace of a rare failure in TestConcurrentEvents (test_two_watchpoints_one_signal_dwarf). Unfortunately, I do not see a clear way how to avoid it, so I'm writing here in case anyone has an idea.<div><br></div><div>Here is my interpretation of the events, backed by log snippets (full log in the attachment, I also can provide the corresponding core file if anyone wants to dig around).</div><div><br></div><div>The inferior starts out by creating three threads. Of those, two are set up to hit a watchpoint and one signals itself.</div><div><br></div><div><div>411 1426700114.595431000 [7295/729c]: MonitorChildProcessThreadFunction ::waitpid (pid = -29339, &status, options = 1073741824) => pid = 29346, status = 0x00000a7f (STOPPED), signal = 10, exit_state = 0</div></div><div><br></div><div>On line 411 we see llgs catching the USR1(10) signal.</div><div><br></div><div><div>412 1426700114.595450000 [7295/729c]: NativeProcessLinux::MonitorSignal() received signal SIGUSR1 (10) with code SI_TKILL, (siginfo pid = 29339 (not from llgs), waitpid pid = 29346)</div></div><div><br></div><div>Here, we see that the ptrace(GETSIGINFO) call was successful, we get info about the signal and continue on our way, stop all other threads (which hit a watchpoint by the way), report this to lldb, etc. After some back and forth, lldb tells us to resume the inferior and let it process the SIGUSR1 signal.</div><div><br></div><div><div>548 1426700116.644772000 [7295/729a]: NativeProcessLinux::Resume() resuming thread = 29346 with signal SIGUSR1</div></div><div><br></div><div>However, here things get strange. Immediately after that we get a second waitpid notification, </div><div><br></div><div><div>555 1426700116.644896000 [7295/729c]: MonitorChildProcessThreadFunction ::waitpid (pid = -29339, &status, options = 1073741824) => pid = 29346, status = 0x00000a7f (STOPPED), signal = 10, exit_state = 0</div></div><div><br></div><div>This shouldn't happen as we have just reinjected the signal for the process to handle, and no other signal was sent to the thread in the meantime. But we don't know that so we try to process the signal as usual, by calling ptrace(GETSIGINFO).</div><div><br></div><div><div>558 1426700116.644932000 [7295/729c]: ThreadStateCoordinator::EnqueueEvent enqueued event: EventThreadDeath (tid=29346)</div></div><div><div>561 1426700116.644961000 [7295/729c]: NativeProcessLinux::MonitorCallback GetSignalInfo failed: No such process, tid = 29346, signal = 10, status = 0 (thread/process killed, is not main thread, thread metadata removed)</div></div><div><br></div><div>These lines tell us that we are now in the branch where ptrace(GETSIGINFO) failed with ESRCH. This can happen for two reasons:</div><div>- the thread in question has died without us noticing</div><div>- the thread is running</div><div>Since we have just received a waitpid notification, we know that the thread should not be running and we assume that the thread has died between waitpid and getsiginfo calls. We clean up our internal structures and forget about the thread.</div><div><br></div><div>However, the thread is very much alive and kicking and we get another notification from the thread on line 567. Now we try to find the thread in our data structures and assert because it does not exist.</div><div><br></div><div><br></div><div>These events would seem to indicate that the USR1 notification on line 555 was bogus - there should be no additional signal, and even if there was, it should have stopped the thread, but it didn't do that.</div><div><br></div><div>So it seems that we should just ignore bogus signals (= assume they don't stop the thread and they don't kill it). However, it is not easy to differentiate between the three scenarios:</div><div>- real signal - waitpid returns, getsiginfo suceeds - thread is stopped</div><div>- bogus signal - waitpid returns, getsiginfo fails  - thread is running</div><div>- thread death - waitpid returns, getsiginfo fails  - thread is dead</div><div><br></div><div><br></div><div>Does anyone have an idea how to address this? I have a few, but I don't like any of them very much, so I'd rather keep them to myself for now. Besides, this mail has gotten too long already. If you're still reading this, give yourself a cookie. :)</div><span><font color="#888888"><div><br></div><div>pl</div></font></span></div>
</div><br></div>
<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></blockquote></div>