athierry-oct wrote:
Sorry for the long delay, I'm back from vacation and tackling this issue in
parallel with other tasks.
I've started investigating the other failing tests (such as the DAP tests). For
all failing tests, it seems essentially the root cause is the same: moving
events between primary and hijacked listeners exposes places where events were
left unprocessed in the primary listener or hijack listener queue.
Focusing first on `EvaluateExpression()` and `TestCallThatRestarts`, the test
failure is due to a stop event being rebroadcast to the primary listener when
the process stops during expression evaluation, and then being unexpectedly
consumed by `process.Continue()` (see previous messages)
To solve this, at first I thought maybe this stop event should be manually
consumed in the test after the call to `frame.EvaluateExpression()` and before
the call to `process.Continue()`
But now I'm realizing, since the tests are running in sync mode without an
event loop, it seems this event should not have to be handled explicitly by the
user (ie. the python test script in our case).
I also came across the code of `SBDebugger::HandleCommand()`, and noticed that
in sync mode it consumes events after running the command:
```cpp
void SBDebugger::HandleCommand(const char *command) {
LLDB_INSTRUMENT_VA(this, command);
... // Handle the command
// In sync mode, consume events produced by the command
if (!m_opaque_sp->GetAsyncExecution()) {
SBProcess process(GetCommandInterpreter().GetProcess());
ProcessSP process_sp(process.GetSP());
if (process_sp) {
EventSP event_sp;
ListenerSP lldb_listener_sp = m_opaque_sp->GetListener();
while (lldb_listener_sp->GetEventForBroadcaster(
process_sp.get(), event_sp, std::chrono::seconds(0))) {
SBEvent event(event_sp);
HandleProcessEvent(process, event, GetOutputFile(), GetErrorFile());
}
}
}
}
}
```
Would it make sense to do something similar for `SBFrame::EvaluateExpression()`
? This way, events would still be handled transparently when evaluating an
expression in sync mode.
https://github.com/llvm/llvm-project/pull/144919
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
