codelldb icon indicating copy to clipboard operation
codelldb copied to clipboard

No connection could be made...

Open fdncred opened this issue 4 years ago • 18 comments

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.

c:\Users\username\.vscode-insiders\extensions\vadimcn.vscode-lldb-1.5.3\adapter\codelldb.exe terminal-agent --port=6766
Error: Os { code: 10061, kind: ConnectionRefused, message: "No connection could be made because the target machine actively refused it." }
Debug log
Running `cargo build --bin=nu --package=nu --message-format=json`...
    Finished dev [unoptimized + debuginfo] target(s) in 0.79s
Raw artifacts:
{
  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}',
  relativePathBase: 'c:\\Users\\username\\source\\repos\\nushell',
  program: 'c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu.exe',
  sourceLanguages: [ 'rust' ]
}
liblldb: c:\Users\username\.vscode-insiders\extensions\vadimcn.vscode-lldb-1.5.3\lldb\bin\liblldb.dll
libpython: D:\Python\python3.dll
environment: { PYTHONHOME: 'D:\\Python' }
params: { sourceLanguages: [ 'rust' ] }
Listening on port 6895
[2020-06-08T20:22:55Z DEBUG codelldb] New debug session
INFO(Python) 15:22:55 rust: Initializing, module name=rust
DEBUG(Python) 15:22:55 rust: attaching summary get_tuple_summary to "^\(.*\)$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StrSliceSynthProvider to "&str", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StrSliceSynthProvider to "&str", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching synthetic StrSliceSynthProvider to "str*", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StrSliceSynthProvider to "str*", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching synthetic StdStringSynthProvider to "collections::string::String", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdStringSynthProvider to "collections::string::String", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching synthetic StdStringSynthProvider to "alloc::string::String", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdStringSynthProvider to "alloc::string::String", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching synthetic StdVectorSynthProvider to "^collections::vec::Vec<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdVectorSynthProvider to "^collections::vec::Vec<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdVectorSynthProvider to "^alloc::vec::Vec<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdVectorSynthProvider to "^alloc::vec::Vec<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic SliceSynthProvider to "^&(mut\s*)?\[.*\]$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_SliceSynthProvider to "^&(mut\s*)?\[.*\]$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic SliceSynthProvider to "^slice<.>.*$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_SliceSynthProvider to "^slice<.>.*$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdCStringSynthProvider to "std::ffi::c_str::CString", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdCStringSynthProvider to "std::ffi::c_str::CString", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching synthetic StdCStrSynthProvider to "std::ffi::c_str::CStr", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdCStrSynthProvider to "std::ffi::c_str::CStr", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching synthetic StdOsStringSynthProvider to "std::ffi::os_str::OsString", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdOsStringSynthProvider to "std::ffi::os_str::OsString", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching synthetic StdOsStrSynthProvider to "std::ffi::os_str::OsStr", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdOsStrSynthProvider to "std::ffi::os_str::OsStr", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching synthetic StdPathBufSynthProvider to "std::path::PathBuf", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdPathBufSynthProvider to "std::path::PathBuf", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching synthetic StdPathSynthProvider to "std::path::Path", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdPathSynthProvider to "std::path::Path", is_regex=False
DEBUG(Python) 15:22:55 rust: attaching synthetic StdRcSynthProvider to "^alloc::rc::Rc<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdRcSynthProvider to "^alloc::rc::Rc<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdRcSynthProvider to "^alloc::rc::Weak<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdRcSynthProvider to "^alloc::rc::Weak<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdArcSynthProvider to "^alloc::(sync|arc)::Arc<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdArcSynthProvider to "^alloc::(sync|arc)::Arc<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdArcSynthProvider to "^alloc::(sync|arc)::Weak<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdArcSynthProvider to "^alloc::(sync|arc)::Weak<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdMutexSynthProvider to "^std::sync::mutex::Mutex<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdMutexSynthProvider to "^std::sync::mutex::Mutex<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdCellSynthProvider to "^core::cell::Cell<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdCellSynthProvider to "^core::cell::Cell<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdRefCellSynthProvider to "^core::cell::RefCell<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdRefCellSynthProvider to "^core::cell::RefCell<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdRefCellBorrowSynthProvider to "^core::cell::Ref<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdRefCellBorrowSynthProvider to "^core::cell::Ref<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdRefCellBorrowSynthProvider to "^core::cell::RefMut<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdRefCellBorrowSynthProvider to "^core::cell::RefMut<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdHashMapSynthProvider to "^std::collections::hash::map::HashMap<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdHashMapSynthProvider to "^std::collections::hash::map::HashMap<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdHashSetSynthProvider to "^std::collections::hash::set::HashSet<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdHashSetSynthProvider to "^std::collections::hash::set::HashSet<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdOptionSynthProvider to "^core::option::Option<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdOptionSynthProvider to "^core::option::Option<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdResultSynthProvider to "^core::result::Result<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdResultSynthProvider to "^core::result::Result<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching synthetic StdCowSynthProvider to "^alloc::borrow::Cow<.>$", is_regex=True
DEBUG(Python) 15:22:55 rust: attaching summary _get_synth_summary_StdCowSynthProvider to "^alloc::borrow::Cow<.>$", is_regex=True
[2020-06-08T20:22:55Z DEBUG codelldb::dap_codec] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code - Insiders","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true},"type":"request","seq":1}
[2020-06-08T20:22:55Z DEBUG codelldb::dap_codec]  {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Debug executable 'nu'","args":[],"cwd":"C:\\Users\\username\\source\\repos\\nushell","relativePathBase":"c:\\Users\\username\\source\\repos\\nushell","program":"c:\\Users\\username\\source\\repos\\nushell\\target\\debug\\nu.exe","sourceLanguages":["rust"],"_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":["\n"]},"__sessionId":"69a7d8b1-9b5f-41cb-a11f-5621abc42658"},"type":"request","seq":2}
[2020-06-08T20:22:55Z DEBUG codelldb::dap_codec]  {"command":"setBreakpoints","arguments":{"source":{"name":"external.rs","path":"c:\\Users\\username\\source\\repos\\nushell\\crates\\nu-cli\\src\\commands\\classified\\external.rs"},"lines":[181],"breakpoints":[{"line":181}],"sourceModified":false},"type":"request","seq":3}
[2020-06-08T20:22:56Z DEBUG codelldb::dap_codec] --> {"type":"response","seq":4,"command":"runInTerminal","request_seq":2,"success":true,"body":{"shellProcessId":30212}}
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<:hir::spannedexpression>' which does not have a complete definition.
error: nu.exe :: Class 'nu_source::meta::Spanned<:value::primitive::primitive>' has a member 'item' of type 'nu_protocol::value::primitive::Primitive' which does not have a complete definition.
error: nu.exe :: Class 'indexmap::Bucket<:string::string nu_protocol::value::value>' has a member 'value' of type 'nu_protocol::value::Value' which does not have a complete definition.
[2020-06-08T20:23:01Z DEBUG codelldb::dap_codec]  {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5}
[2020-06-08T20:23:01Z DEBUG codelldb::dap_codec]  {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":6}
[2020-06-08T20:23:01Z DEBUG codelldb::dap_codec]  {"command":"setExceptionBreakpoints","arguments":{"filters":["rust_panic"]},"type":"request","seq":7}
[2020-06-08T20:23:01Z DEBUG codelldb::dap_codec] --> {"type":"response","seq":8,"command":"runInTerminal","request_seq":3,"success":true,"body":{"shellProcessId":30212}}
[2020-06-08T20:23:01Z ERROR codelldb::dap_session] Send error: runInTerminal(RunInTerminalResponseBody { process_id: None, shell_process_id: Some(30212) })
[2020-06-08T20:23:05Z DEBUG codelldb::dap_codec]  {"command":"configurationDone","type":"request","seq":9}
[2020-06-08T20:23:05Z DEBUG codelldb::dap_codec]  {"command":"threads","type":"request","seq":10}
[2020-06-08T20:23:05Z DEBUG codelldb::dap_codec]  {"command":"disconnect","arguments":{"restart":false},"type":"request","seq":11}
[2020-06-08T20:23:05Z ERROR codelldb::debug_session] Internal debugger error: cannot destroy process ffffffff while state = 10
[2020-06-08T20:23:05Z DEBUG codelldb::dap_codec] 

fdncred avatar Jun 08 '20 20:06 fdncred

I've been getting a similar error since the most recent CodeLLDB update, only on MacOS (10.14.6):

/Users/rob.ruck/.vscode/extensions/vadimcn.vscode-lldb-1.5.3/adapter/codelldb terminal-agent --port=54229 Error: Os { code: 61, kind: ConnectionRefused, message: "Connection refused" }

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.

RobRuckOB avatar Jun 10 '20 09:06 RobRuckOB

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 "terminal": "console" to use the Debug Console for target output.

vadimcn avatar Jun 10 '20 17:06 vadimcn

"terminal": "console" is no longer valid in vscode. I'm not sure what the new setting is. I'm using vscode 1.46.0, or 1.46.0-insider. image

fdncred avatar Jun 10 '20 18:06 fdncred

Sorry, this goes into the launch configuration. If you want to set it as a default in settings, use "lldb.launch.terminal".

vadimcn avatar Jun 10 '20 19:06 vadimcn

@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<:hir::spannedexpression>' which does not have a complete definition.
error: nu.exe :: Class 'nu_source::meta::Spanned<:value::primitive::primitive>' has a member 'item' of type 'nu_protocol::value::primitive::Primitive' which does not have a complete definition.
error: nu.exe :: Class 'indexmap::Bucket<:string::string nu_protocol::value::value>' 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"
        },
    ]
}

fdncred avatar Jun 12 '20 20:06 fdncred

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.

vadimcn avatar Jun 03 '21 17:06 vadimcn

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 Listening on port 65027 but the adapter is started with the line PS C:\Users\valde\Projects\bvh-visualizer> & 'c:\Users\valde\.vscode\extensions\vadimcn.vscode-lldb-1.6.5\adapter\codelldb.exe' 'terminal-agent' '--port=65029'.

Could it be a temporary fix to simply subtract 2 from the argument?

Tegon-McCloud avatar Sep 04 '21 09:09 Tegon-McCloud

I have the same issue on macOS 11.6.1 (20G224) M1

vadimcn.vscode-lldb-1.6.10/adapter/codelldb terminal-agent --port=53754 Error: Os { code: 61, kind: ConnectionRefused, message: "Connection refused" }

Any update?

xylophone21 avatar Nov 25 '21 01:11 xylophone21

Any update?

No. I was not able to reproduce this so far.

vadimcn avatar Nov 25 '21 22:11 vadimcn

FWIW I had the same issue on Windows 10 and I found a solution in another issue https://github.com/vadimcn/vscode-lldb/issues/410#issuecomment-948286122

0x00A avatar Nov 26 '21 05:11 0x00A

@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.

vadimcn avatar Nov 29 '21 18:11 vadimcn

I have the same issue only on Intel macOS Monterey. Though is most likely related to my use of Nix for installing this extension.

Could it be a temporary fix to simply subtract 2 from the argument?

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 codelldb executable here. From the docs.

Binding with a port number of 0 will request that the OS assigns a port to this listener. The port allocated can be queried via the TcpListener::local_addr method.

The port just so happens to always be two off.

Running the command LLDB Run Diagnostics from within Visual Studio works, I'm still not sure as to what the actual problem is.

I have wrapper scripts in place of the replace codelldb:

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"  "$@"

adapter/.codelldb-wrapped is the actual executable.

My current working theory is that the environment variables are dropped for lack of a better word, when the executable codelldb re-enters it self when attempting to create a debug terminal here. As it won't run the wrapper scripts again.

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 "lldb.launch.terminal": "external" set.

nigelgbanks avatar Dec 03 '21 14:12 nigelgbanks

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}"
        }
      ]
    }

MunchyYDL avatar Jan 09 '22 20:01 MunchyYDL

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? So far, I've "lldb.verboseLogging": true turned on, but still cannot figure out why.


Update: After some hard investigations, I find that, if I start VS code with sudo (though VS Code is against this), the debug feature works fine. Some mysterious service on my machine is blocking codelldb from launching new process.

[2022-01-26T12:44:45.987Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":5,"event":"output","body":{"output":"Launching: <path-to-my-app>\n"}}
[2022-01-26T12:44:46.137Z ERROR codelldb::debug_session] process exited with status -1 (Error 1)

alanhe avatar Jan 24 '22 10:01 alanhe

In my program the debugger runs fine if main is like this: fn main() { // insert non networking code } but If I add networking code: #[tokio::main] async fn main() -> std::io::Result<()> {

HttpServer::new(|| {
    App::new()
    //.route("/", web::get().to(greet))
    //.route("/{name}", web::get().to(greet))
    .route("/health_check", web::get().to(health_check))
})
.bind("127.0.0.1:8000")?
.run()
.await

} then I get that connection refused.

charlesboudousquie avatar Feb 03 '22 23:02 charlesboudousquie

I also get this error. It is similar to the errors of #635, although I don't use tokio.

.... which does not have a complete definition

aminya avatar Feb 14 '22 08:02 aminya

I fixed it on my end. How: Turns out that I was using lldb debugger instead of the c++ debugger https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools lldb is not usable as a debugger on WINDOWS. If youre using windows you have to use the c++ extension instead. lldb only works for linux and mac.

charlesboudousquie avatar Feb 22 '22 03:02 charlesboudousquie

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."
"Source: CodeLLDB (extension)"

vscode breakpoints:
[x]C++: on throw
[ ]C++: on catch

The Poweshell terminal clears so I can't see it, but using up arrow key for command history I get

'c:\Users\John\.vscode\extensions\vadimcn.vscode-lldb-1.7.3\adapter\codelldb.exe' 'terminal-agent' '--connect=60737' 

when I press enter I get

Error: Os { code: 10061, kind: ConnectionRefused, message: "No connection could be made because the target machine actively refused it." }

When I uncheck both breakpoints then vscode debugging run succeeds.

vscode breakpoints:
[ ]C++: on throw
[ ]C++: on catch

I can add my own breakpoints and vscode debugging works

johndelavega avatar Aug 11 '22 20:08 johndelavega

same problem with vscode rust codelldb in win11

lost22git avatar Oct 04 '22 20:10 lost22git

@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?

vadimcn avatar Oct 04 '22 22:10 vadimcn

@vadimcn

Error: Os { code: 10061, kind: ConnectionRefused, message: "No connection could be made because the target machine actively refused it." }

v1.8.1

lost22git avatar Oct 05 '22 11:10 lost22git

@lost4git What about the other question:

Are you seeing an adapter crash, or just the "No connection could be made..." message?

vadimcn avatar Oct 05 '22 17:10 vadimcn

@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.

aminya avatar Aug 21 '23 17:08 aminya