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
