-
Notifications
You must be signed in to change notification settings - Fork 261
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
No connection could be made... #323
Comments
I've been getting a similar error since the most recent CodeLLDB update, only on MacOS (10.14.6):
After a lot of tries it will eventually work. I hadn't noticed if the port was changing every time for me, but if that was the case, I guess it eventually hits on a port that isn't currently in use and so works. |
Since this happened on different OS'es, I would suspect some sort of race condition existing when the terminal agent reverse-connects to the main debugger process. :-\ For now, you can set |
Sorry, this goes into the launch configuration. If you want to set it as a default in settings, use "lldb.launch.terminal". |
@vadimcn Thanks but that didn't make any difference. I've used your lldb in the past with great success however recently I haven't be able to. I'm not sure if it's something new on your end or something new on my end that preventing it from working properly. Any further tips would be appreciated. Debug log (not verbose)Running `cargo build --workspace --features=stable --message-format=json`... Compiling nu_plugin_textview v0.15.0 (C:\Users\username\source\repos\nushell\crates\nu_plugin_textview) Compiling nu_plugin_match v0.15.0 (C:\Users\username\source\repos\nushell\crates\nu_plugin_match) Compiling nu_plugin_inc v0.15.0 (C:\Users\username\source\repos\nushell\crates\nu_plugin_inc) Compiling nu_plugin_post v0.15.0 (C:\Users\username\source\repos\nushell\crates\nu_plugin_post) Compiling nu_plugin_fetch v0.15.0 (C:\Users\username\source\repos\nushell\crates\nu_plugin_fetch) Compiling nu_plugin_sys v0.15.0 (C:\Users\username\source\repos\nushell\crates\nu_plugin_sys) Compiling nu_plugin_tree v0.15.0 (C:\Users\username\source\repos\nushell\crates\nu_plugin_tree) Compiling nu_plugin_binaryview v0.15.0 (C:\Users\username\source\repos\nushell\crates\nu_plugin_binaryview) Compiling nu_plugin_ps v0.15.0 (C:\Users\username\source\repos\nushell\crates\nu_plugin_ps) Compiling nu v0.15.0 (C:\Users\username\source\repos\nushell) Compiling nu_plugin_start v0.15.0 (C:\Users\username\source\repos\nushell\crates\nu_plugin_start) Finished dev [unoptimized + debuginfo] target(s) in 38.28s Raw artifacts: { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_inc.exe', name: 'nu_plugin_inc', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_textview.exe', name: 'nu_plugin_textview', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_match.exe', name: 'nu_plugin_match', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_post.exe', name: 'nu_plugin_post', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_fetch.exe', name: 'nu_plugin_fetch', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_tree.exe', name: 'nu_plugin_tree', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_start.exe', name: 'nu_plugin_start', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_sys.exe', name: 'nu_plugin_sys', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_ps.exe', name: 'nu_plugin_ps', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_binaryview.exe', name: 'nu_plugin_binaryview', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_core_inc.exe', name: 'nu_plugin_core_inc', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_stable_post.exe', name: 'nu_plugin_stable_post', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_stable_start.exe', name: 'nu_plugin_stable_start', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_core_sys.exe', name: 'nu_plugin_core_sys', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_core_ps.exe', name: 'nu_plugin_core_ps', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_stable_match.exe', name: 'nu_plugin_stable_match', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_stable_binaryview.exe', name: 'nu_plugin_stable_binaryview', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_stable_fetch.exe', name: 'nu_plugin_stable_fetch', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_stable_tree.exe', name: 'nu_plugin_stable_tree', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu_plugin_core_textview.exe', name: 'nu_plugin_core_textview', kind: 'bin' } { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu.exe', name: 'nu', kind: 'bin' } Filtered artifacts: { fileName: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu.exe', name: 'nu', kind: 'bin' } configuration: { type: 'lldb', request: 'launch', name: "Debug executable 'nu'", args: [], cwd: '${workspaceFolder}', terminal: 'console', relativePathBase: 'c:\\Users\\username\\source\\repos\\nushell', program: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu.exe', sourceLanguages: [ 'rust' ] } Listening on port 2947 error: nu.exe :: Class 'nu_protocol::hir::Binary' has a member 'left' of type 'nu_protocol::hir::SpannedExpression' which does not have a complete definition. error: nu.exe :: Class 'nu_protocol::hir::Expression' has a member '__0' of type 'alloc::vec::Vec' which does not have a complete definition. error: nu.exe :: Class 'nu_source::meta::Spanned' has a member 'item' of type 'nu_protocol::value::primitive::Primitive' which does not have a complete definition. error: nu.exe :: Class 'indexmap::Bucket' has a member 'value' of type 'nu_protocol::value::Value' which does not have a complete definition. Welcome to Nushell 0.15.0 (type 'help' for more info) [2020-06-12T20:01:16Z ERROR codelldb::debug_session] Internal debugger error: cannot destroy process ffffffff while state = 10 Debug adapter exit code=0, signal=null. Launch Configuration{ // 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 executable 'nu'", "cargo": { "args": [ "build", // "--bin=nu", // "--package=nu" "--workspace", "--features=stable" ], "filter": { "name": "nu", "kind": "bin" } }, //"args": ["-c \"sys | get mem\""], //"args": ["-c ls"], "args":[], "cwd": "${workspaceFolder}", "terminal": "console" }, ] } |
CodeLLDB uses a helper process launched in the terminal, which communicates with the main adapter process via TCP/IP. On Windows, it sometimes fails to establish this connection. This never happens on my machine, so I can't investigate. I would appreciate is someone could figure out what's going on. |
I have this issue on Windows. The problem seems to be that the main and adapter processes does not agree on the port to use. In the LLDB output it the port is always 2 lower than the port the adapter process is taking as an agument. Eg the LLDB output says Could it be a temporary fix to simply subtract 2 from the argument? |
I have the same issue on macOS 11.6.1 (20G224) M1 vadimcn.vscode-lldb-1.6.10/adapter/codelldb terminal-agent --port=53754 Any update? |
No. I was not able to reproduce this so far. |
FWIW I had the same issue on Windows 10 and I found a solution in another issue #410 (comment) |
@0x00A The issue you've referenced concerns main codelldb process crashing due to segfault in msdia140.dll, so, naturally, the terminal agent is unable to establish a connection to it. This one, however, is about when the the debug session runs and completes successfully, other than being unable to redirect debuggee's output to the terminal. |
I have the same issue only on Intel macOS Monterey. Though is most likely related to my use of Nix for installing this extension.
I'm seeing this as well, but I don't think it's related. From reading the code the first port that is printed is what the Visual Studio Code DebugAdapterServer is connecting to and that seems to be successful. The second port that is printed comes from the
The port just so happens to always be two off. Running the command I have wrapper scripts in place of the replace adapter/codelldb: #! /nix/store/r42x7q316gznkm5y9b0cl4564g174zyl-bash-5.1-p8/bin/bash -e
export PATH='/nix/store/x0fw0l4d6zwgfdwbpp23iwhm3c6a1hh3-python3-3.9.6/bin'${PATH:+':'}$PATH
export LD_LIBRARY_PATH='/nix/store/x0fw0l4d6zwgfdwbpp23iwhm3c6a1hh3-python3-3.9.6/lib'${LD_LIBRARY_PATH:+':'}$LD_LIBRARY_PATH
exec -a "$0" "/nix/store/84zay225zfzqv4gl1dabhwp72775ff70-vscode-extension-vadimcn-vscode-lldb-1.6.8/share/vscode/extensions/vadimcn.vscode-lldb/adapter/.codelldb-wrapped_" "$@" adapter/.codelldb-wrapped_: #! /nix/store/r42x7q316gznkm5y9b0cl4564g174zyl-bash-5.1-p8/bin/bash -e
export LLDB_DEBUGSERVER_PATH=${LLDB_DEBUGSERVER_PATH-'/nix/store/882magbkjz6ysdisbcxiqkbqhj0r5ppf-lldb-12.0.1/bin/lldb-server'}
exec -a "$0" "/nix/store/84zay225zfzqv4gl1dabhwp72775ff70-vscode-extension-vadimcn-vscode-lldb-1.6.8/share/vscode/extensions/vadimcn.vscode-lldb/adapter/.codelldb-wrapped" "$@"
My current working theory is that the environment variables are EDIT: I've tested by wrapping the launching of Visual Studio Code so that the environment variables were set, but that didn't seem to fix anything, I was able to confirm that the variables were by looking at the history of the terminal with |
I've run in to this problem as well, and while I don't have any more information about why it fails, at least for me, I can always start the debug-process for my unit-tests. Don't know if this can give some clue to anything? Please tell me if you need any kind of additional info, and I'll try to help. :) launch.json
As you can see, this is the regular default launch.json that is automatically created: {
// 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 executable 'iv'",
"cargo": {
"args": [
"build",
"--bin=iv",
"--package=iv"
],
"filter": {
"name": "iv",
"kind": "bin"
}
},
"args": [],
"cwd": "${workspaceFolder}"
},
{
"type": "lldb",
"request": "launch",
"name": "Debug unit tests in executable 'iv'",
"cargo": {
"args": [
"test",
"--no-run",
"--bin=iv",
"--package=iv"
],
"filter": {
"name": "iv",
"kind": "bin"
}
},
"args": [],
"cwd": "${workspaceFolder}"
}
]
} |
I've similar problems on my Mac. When I try to debug Rust, I get "process exited with status -1 (Error 1)". But when I debug the same code in a .devcontainer, it works somehow. I've reinstalled everything: Rust / VS Code. I deleted the extensions folder in ~/.vscode and reinstall the extension too. Is there a config in launch.json that I can print all the commands send to lldb? -- so that I can manually reply every steps to know what's wrong with my environment? Update: After some hard investigations, I find that, if I start VS code with
|
In my program the debugger runs fine if main is like this:
} |
I also get this error. It is similar to the errors of #635, although I don't use tokio.
|
I fixed it on my end. |
I am able to run CodeLLDB on Windows 10 with Rust debugging and tokio dependency There are 2 breakpoints that shows up below in vscode that cannot be deleted but can be disabled. When either "[x] C++: on throw|catch" is checked then debugging fails and I get a dialog message that says "Oops! The debug adapter terminated abnormally."
The Poweshell terminal clears so I can't see it, but using up arrow key for command history I get
when I press enter I get
When I uncheck both breakpoints then vscode debugging run succeeds.
I can add my own breakpoints and vscode debugging works |
same problem with vscode rust codelldb in win11 |
@lost4git Can you please clarify? Are you seeing an adapter crash, or just the "No connection could be made..." message? What is your codelldb version? |
Error: Os { code: 10061, kind: ConnectionRefused, message: "No connection could be made because the target machine actively refused it." } v1.8.1 |
@lost4git What about the other question:
|
@vadimcn I think CodeLLDB should log more information on why this error happens. Everyone in this thread had different reasons, making it hard to pinpoint the issues. |
OS: Windows 10 2004
VSCode version: 1.46.0-insider
Extension version: 1.5.3
Toolchain version: stable-x86_64-pc-windows-msvc (default), rustc 1.43.1 (8d69840ab 2020-05-04)
Build target: stable-x86_64-pc-windows-msvc
Python version: Mini-conda 3.7.6, set as "lldb.adapterEnv": { "PYTHONHOME": "D:\Python" }
I've run this a dozen times, the port always changes. Google thinks something is blocking the port or there's nothing listening on the other side. I have completely disabled Windows firewall. I'm not sure what else could be blocking it. Any ideas how to fix this?
Toward the bottom I can see the launch banner of my application (Welcome to Nushell 0.14.1 (type 'help' for more info)) but then for some reason everything appears to shut down.
Debug log
The text was updated successfully, but these errors were encountered: