Race condition in lldb-mi

Hi Greg,
I have been trying to track down some race condition in lldb-mi which causes tests to fails randomly on buildbots. It seems that problems occurs due to the stop at entry breakpoint. LLDB-mi gets its notification and its starts getting information about frame. But the target has run again and lldb-mi may end up creating a garbage stack frame which persists because lldb clears frame in resume. When it stops at the real breakpoint (say at main), it ends up showing the same garbage stack frame. I tried to look into normal lldb to see how it deal with the entry breakpoint and it seems that GetRestartedFromEvent() does some magic.

I put the following code in the lldb-mi event handler and the problem seems to go away.
    if (lldb::SBProcess::GetRestartedFromEvent (vEvent))
        return true;

But I am not sure what GetRestartedFromEvent() actually means. What will be the best way to ignore the event that comes when entry breakpoint is hit?

Thanks,
Abid

Hi Greg,
I have been trying to track down some race condition in lldb-mi which causes tests to fails randomly on buildbots. It seems that problems occurs due to the stop at entry breakpoint. LLDB-mi gets its notification and its starts getting information about frame. But the target has run again and lldb-mi may end up creating a garbage stack frame which persists because lldb clears frame in resume. When it stops at the real breakpoint (say at main), it ends up showing the same garbage stack frame. I tried to look into normal lldb to see how it deal with the entry breakpoint and it seems that GetRestartedFromEvent() does some magic.

I put the following code in the lldb-mi event handler and the problem seems to go away.
   if (lldb::SBProcess::GetRestartedFromEvent (vEvent))
       return true;

But I am not sure what GetRestartedFromEvent() actually means. What will be the best way to ignore the event that comes when entry breakpoint is hit?

If you hit a breakpoint and any of the breakpoint actions continue the process, the program running LLDB still may want to know that the breakpoint was hit - after all, you might want to update the Breakpoint hit count in your UI somewhere or whatever, or otherwise indicate that the breakpoint DID get hit. So the breakpoint stop event will still be sent to inform you of this. But you also need to know that the target is no longer in a stopped state because of the continue, which is want GetRestartedFromEvent tells you.

So any time you get a stopped event you should always check GetRestartedFromEvent before carrying on with whatever you were going to do. This is exactly the correct thing to do.

Jim

You are doing the right thing. As Jim said any eStateStopped event must check for GetRestartedFromEvent() just in case.

Greg