Ah yes, i was talking about API calls, not command. I'll refrain from writing mails to the list after 10 hours of dev. Sorry for the confusion. On Oct 23, 2014 8:30 PM, "Greg Clayton" <gclay...@apple.com> wrote:
> > > On Oct 23, 2014, at 11:12 AM, Mario Zechner <badlogicga...@gmail.com> > wrote: > > > > Thanks for the eStopReasonTrace explanation. > > > > 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. > > This is fine. > > > However, the event thread may occassionaly send commands as well in > reaction to an event it polls from the process. > > Commands? Not API calls? Be sure to try and not send commands if you can > actually do stuff via the public API. > > If they are commands, and your event handling thread is trying to send > these via SBDebugger::HandleCommand(...) or > SBCommandInterpreter::HandleCommand(), I would suggest you have a way to > send a command over to the command interpreter thread and have it execute > it on the command interpereter thread and then use a condition variable to > wait for the command to complete in the event handling thread. This will > ensure all commands coming into the command interpreter are correctly > serialized. Otherwise you might run into problems where one is running > "step" and another is doing "frame variable x" and the frame variable > command can fail due to the process being run bye the "step" command the > user entered... > > > > Thanks for all the info! > > > > On Oct 23, 2014 8:01 PM, <jing...@apple.com> wrote: > > > > > On Oct 23, 2014, at 10:00 AM, Mario Zechner <badlogicga...@gmail.com> > wrote: > > > > > > 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. > > > > > > 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? > > > > 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. > > > > > > > > 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? > > > > 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. > > > > Jim > > > > > > > > > > On Thu, Oct 23, 2014 at 6:35 PM, Greg Clayton <gclay...@apple.com> > wrote: > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > Greg > > > > > > > On Oct 23, 2014, at 7:29 AM, Mario Zechner <badlogicga...@gmail.com> > wrote: > > > > > > > > Hi, > > > > > > > > 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? > > > > > > > > Thanks, > > > > Mario > > > > _______________________________________________ > > > > lldb-dev mailing list > > > > lldb-dev@cs.uiuc.edu > > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > > > > _______________________________________________ > > > lldb-dev mailing list > > > lldb-dev@cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
