[Lldb-commits] [PATCH] D119548: [lldb] Fix race condition between lldb-vscode and stop hooks executor

Jim Ingham via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Mon Feb 14 16:15:03 PST 2022


jingham added a comment.

I'm a little confused by the analysis so far.  SBTarget.Launch calls Target::Launch.  That sets up a hijacker for the "stop at the first instruction" event regardless of the Sync mode.  Once that succeeds, if the Debugger is set for Synchronous execution Target::Launch does:

  if (synchronous_execution) {
    // Now we have handled the stop-from-attach, and we are just
    // switching to a synchronous resume.  So we should switch to the
    // SyncResume hijacker.
    m_process_sp->RestoreProcessEvents();
    m_process_sp->ResumeSynchronous(stream);

and ResumeSynchronous sets up a Hijacker to wait for and consume the stop event for the first "user stop" after the launch:

  ListenerSP listener_sp(
      Listener::MakeListener(g_resume_sync_name));
  HijackProcessEvents(listener_sp);
  
  Status error = PrivateResume();
  if (error.Success()) {
    StateType state = WaitForProcessToStop(llvm::None, nullptr, true,
                                           listener_sp, stream);

This is the same routine used by all the "target running" commands in sync mode.

So I don't see how your event listening thread could have heard about the second stop event as the events should not have been sent to it.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119548/new/

https://reviews.llvm.org/D119548



More information about the lldb-commits mailing list