<p dir="ltr">Thanks for the eStopReasonTrace explanation.</p>
<p dir="ltr">I may have misstated my setup. I only have a single thread polling for process events, while the other thread merely sends commands to the process. However, the event thread may occassionaly send commands as well in reaction to an event it polls from the process.</p>
<p dir="ltr">Thanks for all the info!</p>
<div class="gmail_quote">On Oct 23, 2014 8:01 PM,  <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Oct 23, 2014, at 10:00 AM, Mario Zechner <<a href="mailto:badlogicgames@gmail.com">badlogicgames@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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?<br>
<br>
eStopReasonTrace means we requested on thread to run on instruction (on most modern processors this is implemented by setting the trace bit in some flags register, thus the name) and the single instruction step completed.  This stop reason actually happens a lot, but you generally shouldn't see it because single stepping is usually used to implement some larger purpose, and we'll convert the eStopReasonTrace to a stop reason appropriate to that larger purpose when we actually get around to returning control to the public layers of lldb.<br>
<br>
><br>
> 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?<br>
<br>
You should not have more than one listener listening for process events.  Greg just fixed some bugs in how commands that run in synchronous mode protect the process event source when they are waiting to complete their synchronous operation.  That could also cause this sort of thing.<br>
<br>
Jim<br>
<br>
<br>
><br>
> On Thu, Oct 23, 2014 at 6:35 PM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
> 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>
><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>
> > _______________________________________________<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>
> 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>