[lldb-dev] What triggers eStopReasonInvalid?

[Mario Zechner]

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?

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?

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141023/3e9c29a1/attachment.html>