Spurious process state change events

Subprojects LLDB
1

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!

2

+lldb-dev

3

+lldb-dev

Thanks, that was it!

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

4

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

5

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