codelldb: Fails to create terminal on MacOS
- Which OS: MacOS Mojave 10.14.4 (Xcode-10.2.1)
- Which VSCode version: Version 1.33.1 (1.33.1) ()
- Which extension version: 1.2.2
- Which adapter type: “classic”
- Which LLDB version: lldb-1001.0.13.3 Swift-5.0
What is the problem and how did you get there:
Internal debugger error: Failed to create a new terminal: timeout
Attempting to debug a Rust program by setting up a breakpoint, and running Debug: “Debug executable ‘rust-class-1’”. The difficulty is that this executable requests user input from stdin.
When I ran this without "terminal":"integrated" added to the launch.json, it simply did not pass the input to the program (so it was hanging forever waiting for input, as the breakpoint was located in the code after the input was consumed).
When I added the above (saw it in https://users.rust-lang.org/t/entering-user-input-to-program-in-vscode-debugger/22722), the following error appeared:
Internal debugger error: Failed to create a new terminal: timeout
Here’s the debug output:
Display settings: variable format=auto, show disassembly=auto, numeric pointer values=off, container summaries=on.
Internal debugger error:
Traceback (most recent call last):
File "/Users/uri/.vscode/extensions/vadimcn.vscode-lldb-1.2.2/adapter/debugsession.py", line 723, in DEBUG_configurationDone
result = self.do_launch(self.launch_args)
File "/Users/uri/.vscode/extensions/vadimcn.vscode-lldb-1.2.2/adapter/debugsession.py", line 155, in complete_launch
stdio, extra_flags = self.configure_stdio(args)
File "/Users/uri/.vscode/extensions/vadimcn.vscode-lldb-1.2.2/adapter/debugsession.py", line 345, in configure_stdio
lambda args: self.spawn_vscode_terminal(kind=term_type, args=args, title=title))
File "/Users/uri/.vscode/extensions/vadimcn.vscode-lldb-1.2.2/adapter/terminal.py", line 49, in create
raise Exception('Failed to create a new terminal: %s' % reason)
Exception: Failed to create a new terminal: timeout
Here’s launch.json:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "lldb",
"request": "launch",
"name": "Debug unit tests in library 'rust-class-1'",
"sourceLanguages": ["rust"],
"cargo": {
"args": [
"test",
"--no-run",
"--lib",
"--package=rust-class-1"
],
"filter": {
"name": "rust-class-1",
"kind": "lib"
}
},
"terminal":"integrated",
"args": [],
"cwd": "${workspaceFolder}"
},
{
"type": "lldb",
"request": "launch",
"name": "Debug executable 'rust-class-1'",
"cargo": {
"args": [
"build",
"--bin=rust-class-1",
"--package=rust-class-1"
],
"filter": {
"name": "rust-class-1",
"kind": "bin"
}
},
"terminal":"integrated",
"lldb.verboseLogging":true,
"args": [],
"sourceLanguages": ["rust"],
"cwd": "${workspaceFolder}"
},
{
"type": "lldb",
"request": "launch",
"name": "Debug unit tests in executable 'rust-class-1'",
"cargo": {
"args": [
"test",
"--no-run",
"--bin=rust-class-1",
"--package=rust-class-1"
],
"filter": {
"name": "rust-class-1",
"kind": "bin"
}
},
"terminal":"integrated",
"args": [],
"sourceLanguages": ["rust"],
"cwd": "${workspaceFolder}"
}
]
}
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 21 (9 by maintainers)
As I understand, all those timeouts are for the Python extension. They shouldm’t have had any effect of Python running inside LLDB. Could this be just a coincidence? Does the problem reappear if you set these settings back to defaults?
This is a spurious break in process startup code, that sometimes happens on slower machines. You should be able to hit the “continue” button and stop at breakpoints in your main program. Do the breakpoints appear resolved (i.e. red, not grayed out)? Do you see source for any code at all?
BTW, have you tried the “native” adapter?
("lldb.adapterType": "native"). It has more bug fixes at this point than the legacy Python code.