Previously the test was written in a way that may be flaky, fixed with
the following changes.
- The breakpoint are placed on functions and set during the
configuration stage of the protocol.
- Add the rpath to the test binary.
- Check we also hit the breakpoint we set directly using lldb.
Improving stability of the TestDAP_launch_commands test.
When collecting output for verifying 'stopCommands' we were not waiting
for the output to finish, which could cause issues if the test is
running very fast.
EvaluateRequests handler now uses the target's context if no valid
frameId is provided, enabling evaluation of
global variables without requiring a valid stack frame.
In repl mode it now uses the last `successful` variable or command
expression, if the provided user's expression is empty.
Try to evaluate the expression if the evaluation context is `Unknown`
We are waiting for both stopped event at once.
We may not get both events within the (0.25 seconds) time interval to
fetch more events. Retry with the `DEFAULT TIMEOUT` if we got one of the
event.
Increase the `EVENT_QUIET_PERIOD`'s value for ASAN mode
Fixes#179648
Updates the 'stopped' event to use structure types.
Additionally, I adjusted the description to include the full
`GetStopDescription` that can have more details.
Closes#119784
Probably closes#147105 as well, but I couldn't test due to #156473:
This PR fixes two bugs:
1. It generates unique variable reference IDs per suspended debuggee
state.
2. It stores all created variables in a stopped state instead of
dropping variables in unselected scopes. So it can properly handle all
scope/variable requests
It does this by storing all variables in their respective scopes and
using that mapping in request handlers that relied on the old mapping.
It dynamically creates new variable/scope IDs instead of resetting IDs
whenever a new scope is created.
I also removed some unused code as well.
---------
Co-authored-by: Med Ismail Bennani <ismail@bennani.ma>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Co-authored-by: Ebuka Ezike <yerimyah1@gmail.com>
non-darwin platforms may have incorrect stop information location
heuristics. Enable assertion once UBSan stopInfo heuristic is updated.
I hit this locally, I don't see it hitting any CI bot but should, Mostly
likely the CI linux bots may not have `compiler_rt` run time enabled.
see
https://github.com/llvm/llvm-project/pull/177964#discussion_r2732271531
In the exceptionInfo request I've added additional information for crash
data, instrumentation data and more detailed exception data.
For example, when UBSan is enabled, you now see additional information
in the exception stack trace about the detected issue:
<img width="1728" height="538" alt="Screenshot 2026-01-15 at 3 05 08 PM"
src="https://github.com/user-attachments/assets/b761af2c-90ac-4eb7-9926-3ab133f1b753"
/>
I included a new test for stopping at `lldb::eStopReasonInstrumentation`
and ensuring we have additional information reported.
---------
Co-authored-by: Ebuka Ezike <yerimyah1@gmail.com>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Investigating some of the biggest slow downs during tests, the biggest
offender is 'wait_for_stopped' requiring a negative assertion around the
'stopped' event.
It currently waits for a negative predicate to fail before continuing.
This means it must wait for the full DEFAULT_TIMEOUT (50s) before the
test is allowed to continue.
To mitigate this, I added a new `collect_events` helper that will wait
for the given event to occur with the DEFAULT_TIMEOUT, then wait for a
quiet period (0.25s) before returning.
This greatly reduces the amount of idle waiting during tests.
Additionally, looking a the performance of individual test files,
`TestDAP_launch` is the slowest overall test. No individual test is that
slow, but the fact it has so many tests in the same file results in the
test harness waiting for that one file to finish.
To mitigate that, I split `TestDAP_launch` into individual test files
that run in parallel, reducing the runtime locally from over 2mins to
~5s.
# Summary
This patch ensures lldb will not try to read from a PseudoConsole if it
has not been opened.
# Original issue
https://github.com/llvm/llvm-project/pull/168729 introduces support for
the Windows ConPTY in `lldb-dap`. This caused a regression in `lldb`
which was not caught by our tests:
https://github.com/llvm/llvm-project/issues/175652.
This patch fixes https://github.com/llvm/llvm-project/issues/175652.
`lldb_private::ProcessLauncherWindows::LaunchProcess` connects the
debuggee to a PseudoConsole only if:
```cpp
if (hPC != INVALID_HANDLE_VALUE && launch_info.GetNumFileActions() == 0 && launch_info.GetFlags().Test(lldb::eLaunchFlagLaunchInTTY))
```
lldb needs to check the same condition in
`lldb_private::PlatformWindows::DebugProcess` to ensure that it does not
read from a PseudoConsole which has not been opened.
# Side effect
This patch reverts what https://github.com/llvm/llvm-project/pull/168729
did by adding ConPTY support.
https://github.com/llvm/llvm-project/pull/175812 is the proper fix,
however it's causing tests failures which we can't reliably reproduce at
desk. Given https://github.com/llvm/llvm-project/pull/168729 breaks
`22.x` lldb, it's better to revert the change ahead of the release of
`22.x` rather than pushing for the proper fix.
"memory region" can be given an address once and then when repeated,
it will try to find a region just beyond the last one it printed.
This continues until the end of the address space.
Then it gives you an error showing the usage, which is odd because
you just saw a bunch of "memory region" with no options work.
So I've improved the error a bit to imply its to do with the repetition.
Then described the repeating behaviour in the help text.
Previously, completion behavior was inconsistent,
sometimes including the partial token or removing existing user text.
Since LLDB completions includes the partial token by default, we now
strip it before sending to the client.
The completion heuristic:
1. Strip the commandEscapePrefix
2. Request completions from the debugger
3. Get the line at cursor position
4. Calculate the length of any partial token
5. Offset each completion by the partial token length
In all cases, the completion starts from the cursor position. then
offsets by `Length` to the left and inserts the completion.
Examples (single quotes show whitespace and are not part of the input):
```md
| Input | Partial Token | Length | Completion |
|------------|---------------|--------|---------------|
| m | m | 1 | memory |
| `m | m | 1 | memory |
| myfoo. | myfoo. | 6 | myfoo.method( |
| myfoo.fi | myfoo.fi | 7 | myfoo.field |
| myfoo. b | b | 1 | myfoo. bar |
| 'memory ' | | 0 | memory read |
| memory | memory | 6 | memory |
| settings s | s | 1 | settings show |
```
Fixes#176424
Two out of three TestDAP_launch_io.py's test's classes have been failing
on ASAN builds ever since it was added into the repo. The ASAN failure
is not easy to debug, so skip these tests until we fix it.
lldb-dap currently crashes when the first character is non ascii. This
is because we assume that the request column is ascii based instead of
UTF16 code units,
and end up in the middle of a character code point. causing an assertion
since we cannot not send invalid UTF-8 values.
This also handles the case in multilines and the column is outside the
range of the text.
Move completion description to the `CompletionItem.detail` property.
This makes it clear the fields required for attaching to an existing
debug session.
It also makes it easier to check mutually exclusive fields required to
attach.
There are some bugs when launching in terminal with args and stdio
redirection.
- lldb-dap `--stdio` args is passed to the debuggee (should we change
this to use `--` to separate debuggee args from lldb-dap args, similar
to how we handle the `--client` args? ).
#### It also changes the behaviour of stdio redirection.
If a redirection is not specified, it uses to lldb default value. e.g.
```jsonc
"stdio": ["./stdin"]`
// now becomes
"stdio", ["./stdio", "./default_stdout", "./default_stderr"]
// instead of
"stdio", ["./stdin", "./stdin", "./stdin"]
// took quite some time to figure out where my output is going to.
```
Fixes [#174445](https://github.com/llvm/llvm-project/issues/174445)
Other bug I noticed but should be in a different PR.
- debuggee args that contains newline are not properly escaped when sent
to the terminal.
This patch introduces support for `clipboard` context from
[DAP](https://microsoft.github.io/debug-adapter-protocol/specification#Types_Capabilities).
This feature is very useful when you want to copy all nested values from
a structure or a container instead of a summary (e.g. `size = 3` for
vector). I added new short mode for description generation to reduce
output verbosity, which is particularly useful for primitive types.
This patch fixes the indentation of 2 docstrings in
`TestDAP_runInTerminal.py`.
Running `black` on that file with the default settings causes this
change. `darker` does not seem to catch it.
This is a prelude to https://github.com/llvm/llvm-project/pull/174635.
This patch fixes a timeout in the monitor thread of the
`test_by_name_waitFor` test.
Currently, if `self.attach` fails, the `spawn_thread` will never finish
and the test will eventually timeout after the 15mins timeout. We now
ensure that we always join the thread at the end of the test.
Additionally, this change also uses of the `spawnSubprocess` method to
create the process. This should ensure the process is always properly
cleaned up after an exception occurs.
In https://github.com/llvm/llvm-project/pull/170523 it was pointed out
that the spec does specifically specify that launch/attach should not
respond until configurationDone is handled.
This means we do need to support async request handlers. To better align
with the spec, I've added a new `lldb_dap::AsyncRequestHandler`. This is
an additional handler type that allows us to respond at a later point.
Additionally, I refactored `launch` and `attach` to only respond once
the `configurationDone` is complete, specifically during the `PostRun`
operation of the `configurationDone` handler.
I merged some of the common behavior between `RequestHandler` and
`AsyncRequestHandler` into their common `BaseRequestHandler`.
The flow should now be:
```
<-> initialize request / response
--> launch/attach request
<-- event initialized
... optionally ...
<-> setBreakpoints request / response
<-> setFunctionBreakpoints request / response
<-> setExceptionBreakpoints request / response
<-> setInstructionBreakpoints request / response
... finally ...
<-> configurationDone request / response
<-- launch/attach response
```
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This patch migrates `restart` request to structured types. Also, I added
some checks that at least one of the required fields was provided for
`launch` and `attach` requests. Maybe I missed some possible
configurations, so please double check.
Majority of the time users are less interested on the memory address of
a type. It is mostly useful for pointer types (the memory address is
shown).
It makes the view more bloated without adding useful information.
can always fall back to the debug console or watch pane to view the
information if necessary.
This patch refactors the way we check for the windows version in the
`@skipIfWindows` decorator.
The new logic reuses the `expectedCompilerVersion` method logic for the
parsing and comparison of the version.
This patch implements a workaround for a VSCode bug that causes it to
send disassemble requests with empty memory reference. You can find more
detailed description
[here](https://github.com/microsoft/vscode/pull/270361). I propose to
allow empty memory reference and return invalid instructions when this
occurs.
Error log example:
```
1759923554.517830610 (stdio) --> {"command":"disassemble","arguments":{"memoryReference":"","offset":0,"instructionOffset":-50,"instructionCount":50,"resolveSymbols":true},"type":"request","seq":3}
1759923554.518007517 (stdio) queued (command=disassemble seq=3)
1759923554.518254757 (stdio) <-- {"body":{"error":{"format":"invalid arguments for request 'disassemble': malformed memory reference at arguments.memoryReference\n{\n \"instructionCount\": 50,\n \"instructionOffset\": -50,\n \"memoryReference\": /* error: malformed memory reference */ \"\",\n \"offset\": 0,\n \"resolveSymbols\": true\n}","id":3,"showUser":true}},"command":"disassemble","request_seq":3,"seq":0,"success":false,"type":"response"}
```
I am not sure that we should add workaround here when bug on VSCode
side, but I think this bug affects our users. WDYT?
This patch adds support for `dataBreakpointInfoBytes` capability from
DAP. You can test this feature in VSCode (`Add data breakpoint at
address` button in breakpoints tab).
## Summary:
This change introduces a `DAPSessionManager` to enable multiple DAP
sessions to share debugger instances when needed, for things like child
process debugging and some scripting hooks that create dynamically new
targets.
Changes include:
- Add `DAPSessionManager` singleton to track and coordinate all active DAP
sessions
- Support attaching to an existing target via its globally unique target
ID (targetId parameter)
- Share debugger instances across sessions when new targets are created
dynamically
- Refactor event thread management to allow sharing event threads
between sessions and move event thread and event thread handlers to `EventHelpers`
- Add `eBroadcastBitNewTargetCreated` event to notify when new targets are
created
- Extract session names from target creation events
- Defer debugger initialization from 'initialize' request to
'launch'/'attach' requests. The only time the debugger is used currently
in between its creation in `InitializeRequestHandler` and the `Launch`
or `Attach` requests is during the `TelemetryDispatcher` destruction
call at the end of the `DAP::HandleObject` call, so this is safe.
This enables scenarios when new targets are created dynamically so that
the debug adapter can automatically start a new debug session for the
spawned target while sharing the debugger instance.
## Tests:
The refactoring maintains backward compatibility. All existing DAP test
cases pass.
Also added a few basic unit tests for DAPSessionManager
```
>> ninja DAPTests
>> ./tools/lldb/unittests/DAP/DAPTests
>>./bin/llvm-lit -v ../llvm-project/lldb/test/API/tools/lldb-dap/
```
Adding structured types for the evaluate request handler.
This should be mostly a non-functional change. I did catch some spelling
mistakes in our tests ('variable' vs 'variables').
Summary
-------
While dogfooding lldb-dap, I observed that VSCode frequently displays
certain stack frames as greyed out. Although these frames have valid
debug information, double-clicking them shows disassembly instead of
source code. However, running `bt` from the LLDB command line correctly
displays source file and line information for these same frames,
indicating this is an lldb-dap specific issue.
Root Cause
----------
Investigation revealed that `DAP::ResolveSource()` incorrectly uses a
frame's PC address directly to determine whether valid source line
information exists. This approach works for leaf frames, but fails for
non-leaf (caller) frames where the PC points to the return address
immediately after a call instruction. This return address may fall into
compiler-generated code with no associated line information, even though
the actual call site has valid source location data.
The correct approach is to use the symbol context's line entry, which
LLDB resolves by effectively checking PC-1 for non-leaf frames, properly
identifying the line information for the call instruction rather than
the return address.
Testing
-------
Manually tested with VSCode debugging sessions on production workloads.
Verified that non-leaf frames now correctly display source code instead
of disassembly view.
Before the change symptom:
<img width="1013" height="216" alt="image"
src="https://github.com/user-attachments/assets/9487fbc0-f438-4892-a8d2-1437dc25399b"
/>
And here is after the fix:
<img width="1068" height="198" alt="image"
src="https://github.com/user-attachments/assets/0d2ebaa7-cca6-4983-a1d1-1a26ae62c86f"
/>
---------
Co-authored-by: Jeffrey Tan <jeffreytan@fb.com>
In lldb-dap tests, we sometimes spawn subprocesses directly but do not
always correctly clean them up.
This can cause some tests, like the `TestDAP_disconnect.test_attach` to
hang and not properly respect timeouts.
To fix this, I am passing the `lldbtest.Base.spawnSubprocess` helper to
the adapter client so it can be used spawn subprocesses in a way that we
can ensure they're cleaned up.
Noticed this while looking into test stability that the 'entry' stop
reason is not triggering correctly. This should ensure we correctly
trigger the 'entry' stop reason when launching a process with
`"stopOnEntry": true`. I've also updated the tests to ensure we receive
the 'entry' stop reason to catch this regression.
… concurrency." (#165688)""
This reverts commit 17dbd8690e36f8e514fb47f4418f78420d0fc019.
This was causing timeouts on the premerge runners. Reverting for now
until the timeouts trigger within lit and/or we have a better testing
strategy for this.
This reverts commit f205be095609aa61dfac3ae729406e0af2dcd15f.
This new select mechanism has exposed the fact that the resources
the Arm Linux bot has can vary a lot. We do limit it to a low number
of parallel tests but in this case, I think it's write performance
somewhere.
Reland the changes since they work elsewhere, and disable lldb-dap
tests on Arm Linux while I fix our buildbot.
Currently all `runInTerminal` test are skipped in debug builds because,
when attaching it times out parsing the debug symbols of lldb-dap.
Add this test since it is running in teminal.
We currently use a background thread to read the DAP output. This means
the test thread and the background thread can race at times and we may
have inconsistent timing due to these races.
To improve the consistency I've removed the reader thread and instead
switched to using the `selectors` module that wraps `select` in a
platform independent way.
