[lldb-dev] Spurious process state change events

[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 that does not stop:

Got event: running , restarted:  False
Got event: stopped , restarted:  True
Got event: running , restarted:  False
Got event: stopped , restarted:  False

Shall I file a bug about this?

pl

On 19 January 2016 at 19:03, Jim Ingham <jingham at apple.com> wrote:
>
>> On Jan 15, 2016, at 1:49 PM, Vadim Chugunov via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>
>> +lldb-dev
>>
>> On Fri, Jan 15, 2016 at 1:47 PM, Vadim Chugunov <vadimcn at gmail.com> wrote:
>> Thanks, that was it!
>>
>> On Fri, Jan 15, 2016 at 1:00 PM, Pavel Labath <labath at google.com> wrote:
>> Hi,
>>
>> The stopped event should have the "restarted" flag set. You can use
>> the GetRestartedFromEvent function to check for that. (Let me know if
>> they don't). I think you can get this (under varying circumstances) on
>> other platforms as well, so you need to handle this everywhere.
>>
>> Somebody correct me if I'm wrong, but I believe that every restarted
>> should be then followed by a running event.
>
> No, if you get a stop event with the restarted bit set, the next event will be another stop event.  It just seemed annoying, if you already know the process restarted, to have to turn around and wait for the running event.
>
> Jim
>
>
>>
>> cheers,
>> pl
>>
>>
>> On 15 January 2016 at 19:35, Vadim Chugunov via lldb-dev
>> <lldb-dev at lists.llvm.org> wrote:
>> > 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 followed
>> > by eStateStopped and another eStateRunning, without any intervention
>> > on my part.  This messes things up for me somewhat, because my script
>> > thinks that a breakpoint has been hit and tries examine state of the
>> > process.
>> > So I have 2 questions:
>> > - Is it supposed to happen?
>> > - What would be the best way to filter out these spurious stop events?
>> >   if is_linux and is_first_stop_event: ...  feels a bit hacky.
>> >
>> > thanks!
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>