[lldb-dev] Spurious process state change events

Jim Ingham via lldb-dev lldb-dev at lists.llvm.org
Wed Jan 20 09:13:23 PST 2016


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 due to a breakpoint condition or command.

Jim


> On Jan 20, 2016, at 3:59 AM, Pavel Labath <labath at google.com> wrote:
> 
> 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
>> 



More information about the lldb-dev mailing list