-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[lldb-dap] Fix raciness in launch and attach tests #137920
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -167,14 +167,23 @@ static void EventThreadFunction(DAP &dap) { | |
// stop events which we do not want to send an event for. We will | ||
// manually send a stopped event in request_configurationDone(...) | ||
// so don't send any before then. | ||
if (dap.configuration_done_sent) { | ||
// Only report a stopped event if the process was not | ||
// automatically restarted. | ||
if (!lldb::SBProcess::GetRestartedFromEvent(event)) { | ||
SendStdOutStdErr(dap, process); | ||
SendThreadStoppedEvent(dap); | ||
{ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if we didn't start the event thread until the Do we miss any events that would have happened before this point? Or maybe we don't subscribe to process events until we get the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that's not an option. Every process must have an event handler and IIUC (@jimingham should be able to confirm) if you don't handle the event, the process will never get out of the "launching" or "attaching" state. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That is true, but it should only matter if someone actually cares about the process in the mean time. Provided we don't need to inspect the state, a sequence like this should be fine:
But I don't know if that's the case here... Another potential option: If we are sure the event is going to be emitted (and the listener thread is not running), maybe we can wait for the event (synchronously) on the thread which is processing the request. |
||
std::unique_lock<std::mutex> lock(dap.first_stop_mutex); | ||
if (dap.first_stop_state == | ||
DAP::FirstStopState::PendingStopEvent) { | ||
dap.first_stop_state = DAP::FirstStopState::IgnoredStopEvent; | ||
lock.unlock(); | ||
dap.first_stop_cv.notify_one(); | ||
continue; | ||
} | ||
} | ||
|
||
// Only report a stopped event if the process was not | ||
// automatically restarted. | ||
if (!lldb::SBProcess::GetRestartedFromEvent(event)) { | ||
SendStdOutStdErr(dap, process); | ||
SendThreadStoppedEvent(dap); | ||
} | ||
break; | ||
case lldb::eStateRunning: | ||
dap.WillContinue(); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should move this above sending the response to the
configurationDone
.The
initialized
event triggers the rest of the adapter configs (e.g. sending all the breakpoints) and theconfigurationDone
request should be the last in that chain.In theory, could could even move the
dap.WaitForProcessToStop(arguments.timeout);
call out of the attach/launch requests and have that here instead and fully expect the attach/launch flow to be async.