| Age | Commit message (Collapse) | Author |
|---|
|
This reverts the following commits:
a0a82ee19d6f2ff1013407ba4c973bfe5428423f
757bb36a58c7d7151a28c6a5fc7caa2e1f44de87
83b48b13f3a70bf56053e92593270c519859cfd7
b45f1fb377636a34c01e34b89341c97d19975554
d2e153981e62fb2ea781ef456ff744f9893e0733
e2d1bbebbb099c7010a31fad62a9128166ef14a0
71cae12442e7476e6397fd73db05e127bfe2d035
7dd879bdc01297a551196a60bb5a5a90ca4dd1ed
f3b542e3148cfc244f63cb7c987ccf8ebc71942b
Where I had disabled specific tests due to them being flakey on our
Windows on Arm bot.
Clearly this strategy isn't working because
every day I see a new random test failing.
Until something can be done about this, disable
every lldb-dap test on Windows on Arm. The coverage we get is just not
worth spamming contributors
who have nothing to do with lldb-dap.
See #137660
|
|
It is flakey lately on our Windows on Arm bot:
https://lab.llvm.org/buildbot/#/builders/141/builds/11169
======================================================================
ERROR: test_startDebugging (TestDAP_startDebugging.TestDAP_startDebugging.test_startDebugging)
Tests the "startDebugging" reverse request. It makes sure that the IDE can
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2067, in tearDown
Base.tearDown(self)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1105, in tearDown
hook() # try the plain call and hope it works
^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\lldbdap_testcase.py", line 518, in cleanup
self.dap_server.terminate()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\dap_server.py", line 1593, in terminate
raise DebugAdapterProcessError(process.returncode)
dap_server.DebugAdapterProcessError: lldb-dap returned non-zero exit status 1.
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
----------------------------------------------------------------------
See https://github.com/llvm/llvm-project/issues/137660.
I am aware that I am disabling these tests with little thought, and I would
like to be more careful with it but I don't have the knowledge to really
debug these issues.
Having buildbot results we can properly triage is more important to
me personally than finding whatever the underlying issue is. I'm sure
DAP experts will figure it out eventually.
|
|
This is more straight forward refactor of the startup sequence that
reverts parts of ba29e60f9a2222bd5e883579bb78db13fc5a7588. Unlike my
previous attempt, I ended up removing the pending request queue and not
including an `AsyncReqeustHandler` because I don't think we actually
need that at the moment.
The key is that during the startup flow there are 2 parallel operations
happening in the DAP that have different triggers.
* The `initialize` request is sent and once the response is received the
`launch` or `attach` is sent.
* When the `initialized` event is recieved the `setBreakpionts` and
other config requests are made followed by the `configurationDone`
event.
I moved the `initialized` event back to happen in the `PostRun` of the
`launch` or `attach` request handlers. This ensures that we have a valid
target by the time the configuration calls are made. I added also added
a few extra validations that to the `configurationeDone` handler to
ensure we're in an expected state.
I've also fixed up the tests to match the new flow. With the other
additional test fixes in 087a5d2ec7897cd99d3787820711fec76a8e1792 I
think we've narrowed down the main source of test instability that
motivated the startup sequence change.
|
|
This PR changes how we treat the launch sequence in lldb-dap.
- Send the initialized event after we finish handling the initialize
request, rather than after we finish attaching or launching.
- Delay handling the launch and attach request until we have handled
the configurationDone request. The latter is now largely a NO-OP and
only exists to signal lldb-dap that it can handle the launch and
attach requests.
- Delay handling the initial threads requests until we have handled
the launch or attach request.
- Make all attaching and launching synchronous, including when we have
attach or launch commands. This removes the need to synchronize
between the request and event thread.
Background:
https://discourse.llvm.org/t/reliability-of-the-lldb-dap-tests/86125
|
|
request. (#112396)
Adjusting the name from `lldb-dap startDebugging` to `lldb-dap
start-debugging` to improve consistency with other names for commands in
lldb/lldb-dap.
|
|
The don't currently work (and they're also not particularly useful,
since all of the remote stuff happens inside lldb).
This saves us from annotating tests one by one.
|
|
These tests failed in case of Windows host and Linux target, because
dap_server tried to run ELF file on Windows.
|
|
Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:
s/VSCODE/DAP/
s/VSCode/DAP/
s/vscode/dap/
s/g_vsc/g_dap/
Discourse RFC:
https://discourse.llvm.org/t/rfc-rename-lldb-vscode-to-lldb-dap/74075/
|
