Re: [lldb-dev] Spurious process state change events

2016-01-20 Thread Jim Ingham via lldb-dev
Please do file a bug, that's definitely not how things are supposed to work. You will still see a private "running" event, of course, since those are just the raw events from the target, but the running event shouldn't get broadcast to the public event queue if it was coming from a

Re: [lldb-dev] Spurious process state change events

2016-01-20 Thread Pavel Labath via lldb-dev
Hello, thanks for confirming my suspicions. Sending the extra running event seems quite annoying to me as well, but it is how things work at the moment. And the problem does not seem to be linux-specific. This is the sequence of events I get on a Mac, when running over a conditional breakpoint

Re: [lldb-dev] Spurious process state change events

2016-01-19 Thread Jim Ingham via lldb-dev
> On Jan 15, 2016, at 1:49 PM, Vadim Chugunov via lldb-dev > wrote: > > +lldb-dev > > On Fri, Jan 15, 2016 at 1:47 PM, Vadim Chugunov wrote: > Thanks, that was it! > > On Fri, Jan 15, 2016 at 1:00 PM, Pavel Labath wrote: > Hi,

[lldb-dev] Spurious process state change events

2016-01-15 Thread Vadim Chugunov via lldb-dev
Hi, I have a Python script that drives LLDB (in async mode), with a listener attached to the process. On OSX, upon the launch, LLDB emits a eStateRunning process state event, and then eventually eStateStopped - when a breakpoint is hit. On Linux, however, the initial eStateRunning is immediately

Re: [lldb-dev] Spurious process state change events

2016-01-15 Thread Vadim Chugunov via lldb-dev
+lldb-dev On Fri, Jan 15, 2016 at 1:47 PM, Vadim Chugunov wrote: > Thanks, that was it! > > On Fri, Jan 15, 2016 at 1:00 PM, Pavel Labath wrote: > >> Hi, >> >> The stopped event should have the "restarted" flag set. You can use >> the GetRestartedFromEvent