[lldb-dev] What triggers eStopReasonInvalid?

[Mario Zechner]

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" <gclayton at apple.com> wrote:

>
> > On Oct 23, 2014, at 11:12 AM, Mario Zechner <badlogicgames at 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, <jingham at apple.com> wrote:
> >
> > > On Oct 23, 2014, at 10:00 AM, Mario Zechner <badlogicgames at 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 <gclayton at 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 <badlogicgames at 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 at cs.uiuc.edu
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> > >
> > >
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141023/ce48132f/attachment.html>