<div dir="ltr">This is on Mac OS X, so i assume it's a problem in one of the other ProcessXXX classes. It's currently a bit tough to diagnose if this stop event with the eStopReasonInvalid thread states is in response to SBProcess::Stop() or not. I sure does look like a race condition, as it isn't deterministic. E.g. Using a timeout of 0 seconds on SBListener::WaitForEvent will sporadically send those stop events, while they are entirely gone if i use a higher timeout. I'll try to produce a test case that reproduces the issue, but that may take a while.<div><br></div><div>Related, what does eStopReasonTrace mean? I also get that sporadically (using a different test case). Could it be related to the process exiting before the SBProcess::Stop() command is executed?</div><div><br></div><div>I have a feeling that my issues may also stem from the fact that i have two separate threads interacting with LLDB. I have one event polling thread which essentially just calls SBListener::WaitForEvent in a loop and delegates the events to other listeners. The second thread is a command thread that listens for user input and then sends commands such to LLDB, e.g. interrupt the process, continue the process etc. However, sometimes the listeners need to send commands to LLDB as well, which may overlap with sending commands on the command thread. I assume this could be an issue as well?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 23, 2014 at 6:35 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">It really depends on the debugger plugin. I am guessing this would be ProcessLinux that is doing this, and I am not sure if it is intentional.<br>
<br>
When you interrupt a process, you really want the process to stop and have all threads have no valid stop reason since you just wanted to interrupt this. Typically when stopping a process, a SIGSTOP is sent to the process and the lldb_private::Process subclass may or may not try to hide the actual stop reason from you. So this is really a question for the linux guys to answer. Is this stop event you are talking about always in response to when you call Stop? Or does this happen at other times. I would venture a guess that the ProcessLinux plugin is trying to hide the real reason the process stopped because it interrupted the process with SIGSTOP, but the user shouldn't worry about that.<br>
<br>
If this sometimes happens and sometimes doesn't when sending stop, we should find and fix the race condition that allows this to take place and always either return no stop reason (or make a new eStopReasonInterrupted), or return the SIGSTOP signal as the stop reason consistently.<br>
<br>
Greg<br>
<div><div class="h5"><br>
> On Oct 23, 2014, at 7:29 AM, Mario Zechner <<a href="mailto:badlogicgames@gmail.com">badlogicgames@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> i'm currently using SBProcess::Stop() to interrupt a running process. After i perform some tasks, i resume the process with SBProcess:Continue(), which works just fine. However, sporadically and indeterministically i get a stop event, where the stop reason for all threads is set to eStopReasonInvalid. Can anybody give me a hint why that would be?<br>
><br>
> Thanks,<br>
> Mario<br>
</div></div>> _______________________________________________<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><br></div>