[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