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 continuation
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 tha
> 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,
>
> The stopped event should have the "restarted" flag set. You
+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 function to check for that. (Let me kn
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 fo
