Cannot to attach the remote dlv process

Karmenzind commented

2023-02-09 12:59:14 +03:00

(Migrated from github.com)

Environment:

dlv version:
Delve Debugger
Version: 1.20.1
Build: $Id: 96e65b6c615845d42e0e31d903f6475b0e4ece6e $

nvim-dap-go is the latest version
commit b4ded7de579b4e2a85c203388233b54bf1028816 (HEAD -> main, origin/main, origin/HEAD)

/proc/version:
Linux version 6.1.6-arch1-3 (linux@archlinux) (gcc (GCC) 12.2.1 20230111, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT_DYNAMIC Mon, 16 Jan 2023 12:51:23 +0000

Lua config:
require("dap-go").setup({
    dap_configurations = {
        { type = "go", name = "Attach remote", mode = "remote", request = "attach" },
    },
})

Steps to reproduce:

Run my gin project with dlv debug -l 127.0.0.1:38697 --headless xxx/xxx.go
7. Attach Remote raised Error on attach: Failed to attach: no debugger found
Run 4. Attach and input 111 (111: id=1332739 name=dlv debug -l ... in the process list) and it raised Error on attach: Failed to attach: could not attach to pid 1332739: could not open debug info - debuggee must not be built with 'go run' or -ldflags='-s - w', which strip debug info

BTW 1. Debug worked fine but it surpressed the output.

I don't know which part went wrong. Several days ago (before I update my system) I just need to run dlv debug -l 127.0.0.1:38697 --headless xxx/xxx.goand select 4. Attach and it would automatically find the remote process and attach to it.

Environment: ``` dlv version: Delve Debugger Version: 1.20.1 Build: $Id: 96e65b6c615845d42e0e31d903f6475b0e4ece6e $ nvim-dap-go is the latest version commit b4ded7de579b4e2a85c203388233b54bf1028816 (HEAD -> main, origin/main, origin/HEAD) /proc/version: Linux version 6.1.6-arch1-3 (linux@archlinux) (gcc (GCC) 12.2.1 20230111, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT_DYNAMIC Mon, 16 Jan 2023 12:51:23 +0000 Lua config: require("dap-go").setup({ dap_configurations = { { type = "go", name = "Attach remote", mode = "remote", request = "attach" }, }, }) ``` ![image](https://user-images.githubusercontent.com/17923071/217781272-80fd1f38-b403-4421-978d-8ebd8bddecd3.png) Steps to reproduce: 1. Run my gin project with `dlv debug -l 127.0.0.1:38697 --headless xxx/xxx.go` 2. `7. Attach Remote` raised `Error on attach: Failed to attach: no debugger found` 3. Run `4. Attach` and input 111 (`111: id=1332739 name=dlv debug -l ...` in the process list) and it raised `Error on attach: Failed to attach: could not attach to pid 1332739: could not open debug info - debuggee must not be built with 'go run' or -ldflags='-s - w', which strip debug info` BTW `1. Debug` worked fine but it surpressed the output. I don't know which part went wrong. Several days ago (before I update my system) I just need to run `dlv debug -l 127.0.0.1:38697 --headless xxx/xxx.go`and select `4. Attach` and it would automatically find the remote process and attach to it.

👍 5

Kasama commented

2023-03-22 03:29:49 +03:00

(Migrated from github.com)

I'm having the same issue here. Did you get it to work? Some months ago I'm sure it worked, but now I'm getting this Error on attach: Failed to attach: no debugger found.

:lua = require('dap').configurations.go shows

{
  {
    name = "Debug",
    program = "${file}",
    request = "launch",
    type = "go"
  }, {
    args = <function 1>,
    name = "Debug (Arguments)",
    program = "${file}",
    request = "launch",
    type = "go"
  }, {
    name = "Debug Package",
    program = "${fileDirname}",
    request = "launch",
    type = "go"
  }, {
    mode = "local",
    name = "Attach",
    processId = <function 2>,
    request = "attach",
    type = "go"
  }, {
    mode = "test",
    name = "Debug test",
    program = "${file}",
    request = "launch",
    type = "go"
  }, {
    mode = "test",
    name = "Debug test (go.mod)",
    program = "./${relativeFileDirname}",
    request = "launch",
    type = "go"
  }, {
    mode = "remote",
    name = "Attach to remote Delve",
    request = "attach",
    type = "go"
  }
}

and :lua = require('dap').adapters.go

{
  executable = {
    args = { "dap", "-l", "127.0.0.1:${port}" },
    command = "dlv"
  },
  options = {
    initialize_timeout_sec = 20
  },
  port = "${port}",
  type = "server"
}

I'm having the same issue here. Did you get it to work? Some months ago I'm sure it worked, but now I'm getting this `Error on attach: Failed to attach: no debugger found`. `:lua = require('dap').configurations.go` shows ```lua { { name = "Debug", program = "${file}", request = "launch", type = "go" }, { args = <function 1>, name = "Debug (Arguments)", program = "${file}", request = "launch", type = "go" }, { name = "Debug Package", program = "${fileDirname}", request = "launch", type = "go" }, { mode = "local", name = "Attach", processId = <function 2>, request = "attach", type = "go" }, { mode = "test", name = "Debug test", program = "${file}", request = "launch", type = "go" }, { mode = "test", name = "Debug test (go.mod)", program = "./${relativeFileDirname}", request = "launch", type = "go" }, { mode = "remote", name = "Attach to remote Delve", request = "attach", type = "go" } } ``` and `:lua = require('dap').adapters.go` ```lua { executable = { args = { "dap", "-l", "127.0.0.1:${port}" }, command = "dlv" }, options = { initialize_timeout_sec = 20 }, port = "${port}", type = "server" } ```

Kasama commented

2023-03-22 03:34:28 +03:00

(Migrated from github.com)

Nevermind, i think this is a dup of #27.

Adding the following made it work for me

require('dap-go').setup {
  delve = {
    port = "38697",
  },
}

Nevermind, i think this is a dup of #27. Adding the following made it work for me ```lua require('dap-go').setup { delve = { port = "38697", }, } ```

marcomayer commented

2023-04-04 17:01:04 +03:00

(Migrated from github.com)

This also stopped working for me (debugger not found) with the setup from the README:

delve = {
   -- time to wait for delve to initialize the debug session.
   -- default to 20 seconds
   initialize_timeout_sec = 20,
   -- a string that defines the port to start delve debugger.
   -- default to string "${port}" which instructs nvim-dap
   -- to start the process in a random available port
   port = "${port}"
 },

For some reason dropping initialize_timeout_sec fixes it:

delve = {
   port = "${port}"
 },

This also stopped working for me (debugger not found) with the setup from the README: ``` delve = { -- time to wait for delve to initialize the debug session. -- default to 20 seconds initialize_timeout_sec = 20, -- a string that defines the port to start delve debugger. -- default to string "${port}" which instructs nvim-dap -- to start the process in a random available port port = "${port}" }, ``` For some reason dropping `initialize_timeout_sec` fixes it: ``` delve = { port = "${port}" }, ```

manofthelionarmy commented

2023-04-28 02:17:15 +03:00

(Migrated from github.com)

I had this issue to:
I added this to my config to resolve my issue:

require('dap-go').setup {

  dap_configurations = {
    {
      type = "go",
      name = "Attach remote",
      mode = "remote",
      request = "attach",
      -- tell which host and port to connect to
      connect = {
        host = "127.0.0.1",
        port = "8181"
      }
    },
  },
  delve = {
    port = "8181" 
  },
}

I believe it was saying it couldn't find the debugger because it didn't know which host and port to find the headless debugger.

This lead to another issue, I saw in nvim-dap-ui, the repl console was logging dlv couldn't start a headless server because the port was already in use. This is not the correct behavior because we are expecting to connect to a delve headless, not start one. I believe it's because the executable is set:

leoluz/nvim-dap-go@4af956c8ca/lua/dap-go.lua (L65)

I did a hack around to stop this:

require('dap-go').setup {

  dap_configurations = {
    {
      type = "go",
      name = "Attach remote",
      mode = "remote",
      request = "attach",
      -- tell which host and port to connect to
      connect = {
        host = "127.0.0.1",
        port = "8181"
      }
    },
  },
  delve = {
    port = "8181" 
  },
}

-- removing exeutable stops the dlv exit error.
dap.adapters.go = {
    type = "server",
    port = '8181',
    -- executable = {
    --   command = "dlv",
    --   args = { "dap", "-l", "127.0.0.1:" .. config.delve.port },
    -- },
  }

From :h dap.txt

The `Adapter` needs to contain a `type`, which can be one of:

- `executable`, to indicate that nvim-dap must launch the debug adapter. In
  this case nvim-dap will spawn the given process and communicate with it using
  stdio.

- `server`, to indicate that nvim-dap can connect to an already-running
  debug adapter via TCP.
  
  ...
  For `server` the following options are supported:

>
    host?: string             -- host to connect to, defaults to 127.0.0.1
    port:  number|"${port}"   -- port to connect to.
                              -- If "${port}" nvim-dap resolves a free port.
                              -- This is intended to be used with
                              -- `executable.args` further below below
    id?: string               -- Identifier of the adapter. This is used for the
                                 `adapterId` property of the initialize request.
                                  For most debug adapters setting this is not
                                  necessary.

    -- nvim-dap can optionally launch the debug-adapter on each new debug session
    -- And then connect via TCP.
    --
    executable?: {
      command: string       -- command that spawns the server
      args?: string[]       -- command arguments
                            -- ${port} used in the args is replaced with a
                            -- dynamically resolved free port number
      detached?: boolean    -- Spawn the debug adapter in detached mode.
                            -- Defaults to true.
      cwd?: string          -- Working directory
    }

    options?: {
      max_retries?: number  -- Amount of times the client should attempt to
                            -- connect before erroring out.
                            -- There is a 250ms delay between each retry
                            -- Defaults to 14 (3.5 seconds)
    }

According to this:
-- nvim-dap can optionally launch the debug-adapter on each new debug session
we should make this an option.

Wondering if a headless adapter is a possible solution:

dap.adapters.go_headless = {
    type = "server",
    port = config.delve.port,
  }

I had this issue to: I added this to my config to resolve my issue: ``` require('dap-go').setup { dap_configurations = { { type = "go", name = "Attach remote", mode = "remote", request = "attach", -- tell which host and port to connect to connect = { host = "127.0.0.1", port = "8181" } }, }, delve = { port = "8181" }, } ``` I believe it was saying it couldn't find the debugger because it didn't know which host and port to find the headless debugger. This lead to another issue, I saw in nvim-dap-ui, the repl console was logging dlv couldn't start a headless server because the port was already in use. This is not the correct behavior because we are expecting to connect to a delve headless, not start one. I believe it's because the `executable` is set: https://github.com/leoluz/nvim-dap-go/blob/4af956c8ca3ffb3ea00f3006c2eff1aa84c359ca/lua/dap-go.lua#L65 I did a hack around to stop this: ``` require('dap-go').setup { dap_configurations = { { type = "go", name = "Attach remote", mode = "remote", request = "attach", -- tell which host and port to connect to connect = { host = "127.0.0.1", port = "8181" } }, }, delve = { port = "8181" }, } -- removing exeutable stops the dlv exit error. dap.adapters.go = { type = "server", port = '8181', -- executable = { -- command = "dlv", -- args = { "dap", "-l", "127.0.0.1:" .. config.delve.port }, -- }, } ``` From `:h dap.txt` ``` The `Adapter` needs to contain a `type`, which can be one of: - `executable`, to indicate that nvim-dap must launch the debug adapter. In this case nvim-dap will spawn the given process and communicate with it using stdio. - `server`, to indicate that nvim-dap can connect to an already-running debug adapter via TCP. ... For `server` the following options are supported: > host?: string -- host to connect to, defaults to 127.0.0.1 port: number|"${port}" -- port to connect to. -- If "${port}" nvim-dap resolves a free port. -- This is intended to be used with -- `executable.args` further below below id?: string -- Identifier of the adapter. This is used for the `adapterId` property of the initialize request. For most debug adapters setting this is not necessary. -- nvim-dap can optionally launch the debug-adapter on each new debug session -- And then connect via TCP. -- executable?: { command: string -- command that spawns the server args?: string[] -- command arguments -- ${port} used in the args is replaced with a -- dynamically resolved free port number detached?: boolean -- Spawn the debug adapter in detached mode. -- Defaults to true. cwd?: string -- Working directory } options?: { max_retries?: number -- Amount of times the client should attempt to -- connect before erroring out. -- There is a 250ms delay between each retry -- Defaults to 14 (3.5 seconds) } ``` According to this: ` -- nvim-dap can optionally launch the debug-adapter on each new debug session` we should make this an option. Wondering if a headless adapter is a possible solution: ``` dap.adapters.go_headless = { type = "server", port = config.delve.port, } ```

👍 6 🎉 1

marcomayer commented

2023-04-28 11:54:14 +03:00

(Migrated from github.com)

I had this issue to: I added this to my config to resolve my issue

This is really helpful. I have the problem too with the launching dlv instances and solved it differently by stopping them afterwards but this is much better!

Only, issue now is that if you want to debug a test for example it doesn't work anymore. Guess I'll add a function to toggle between the two modes but this needs a fix.

There haven't been any commits and issues/PRs look stale though not sure if this plugin is still maintained @leoluz ?

> I had this issue to: I added this to my config to resolve my issue This is really helpful. I have the problem too with the launching dlv instances and solved it differently by stopping them afterwards but this is much better! Only, issue now is that if you want to debug a test for example it doesn't work anymore. Guess I'll add a function to toggle between the two modes but this needs a fix. There haven't been any commits and issues/PRs look stale though not sure if this plugin is still maintained @leoluz ?

manofthelionarmy commented

2023-04-29 01:21:21 +03:00

(Migrated from github.com)

Only, issue now is that if you want to debug a test for example it doesn't work anymore.

Yeah I figured that'll break that😵😞. Hence, a separate adapter for headless debug servers. Apart from that, I had issues with the attach. Though the go adapter is configured to start the server, the process doesn't get kicked off and I don't see it's pid. And, if I do start a dlv process in headless mode, and attach to its pid via nvim dap, I get an error saying the debug session is already in progress at port 8181 and instead use remote mode to connect to the server. I wonder if the go adapter for attach should be setup as an executable, which can start the server, and we'll see it's pid from nvim dap. Additionally, the attach configuration is changed from local to remote mode.

Update: I tried and the process is not starting.

Welp, it's probably best to go with headless adapter

> Only, issue now is that if you want to debug a test for example it doesn't work anymore. Yeah I figured that'll break that😵😞. Hence, a separate adapter for headless debug servers. Apart from that, I had issues with the attach. Though the go adapter is configured to start the server, the process doesn't get kicked off and I don't see it's pid. And, if I do start a dlv process in headless mode, and attach to its pid via nvim dap, I get an error saying the debug session is already in progress at port 8181 and instead use remote mode to connect to the server. I wonder if the go adapter for attach should be setup as an executable, which can start the server, and we'll see it's pid from nvim dap. Additionally, the attach configuration is changed from local to remote mode. Update: I tried and the process is not starting. Welp, it's probably best to go with headless adapter

marcomayer commented

2023-05-03 10:01:57 +03:00

(Migrated from github.com)

What works for me right now is setting up nvim-dap like this:

	require("dap-go").setup({
		delve = {
			port = "38697",
		},
		dap_configurations = {
			{
				type = "go",
				name = "Attach remote",
				mode = "remote",
				request = "attach",
					},
		},
	})

And starting the debug server with:
while pkill dlv; dlv debug -l 127.0.0.1:38697 --headless ./cmd/main.go; do echo "restarting delve..."; done

So it kills off the dlv started by nvim locally first. Of course this is suboptimal but I didn't have the time to really look into this. But that way both work, attaching to remote or starting one up for test debugging etc.

What works for me right now is setting up nvim-dap like this: ``` require("dap-go").setup({ delve = { port = "38697", }, dap_configurations = { { type = "go", name = "Attach remote", mode = "remote", request = "attach", }, }, }) ``` And starting the debug server with: `while pkill dlv; dlv debug -l 127.0.0.1:38697 --headless ./cmd/main.go; do echo "restarting delve..."; done` So it kills off the dlv started by nvim locally first. Of course this is suboptimal but I didn't have the time to really look into this. But that way both work, attaching to remote or starting one up for test debugging etc.

leoluz commented

2023-05-19 21:49:15 +03:00

(Migrated from github.com)

There haven't been any commits and issues/PRs look stale though not sure if this plugin is still maintained @leoluz ?

@marcomayer Yes it is and I use it often :) I work on it when I have time.
I am also open for PRs and help from the community to do issue triage.

Guess I'll add a function to toggle between the two modes but this needs a fix.

@marcomayer Please feel free to suggest a solution to the problem that you are having.

> There haven't been any commits and issues/PRs look stale though not sure if this plugin is still maintained @leoluz ? @marcomayer Yes it is and I use it often :) I work on it when I have time. I am also open for PRs and help from the community to do issue triage. > Guess I'll add a function to toggle between the two modes but this needs a fix. @marcomayer Please feel free to suggest a solution to the problem that you are having.

psethwick commented

2023-09-07 10:23:06 +03:00

(Migrated from github.com)

FWIW, this config works without the pkill hack:

 require('dap-go').setup {
  dap_configurations = {
    {
      type = "go",
      name = "Attach remote",
      mode = "remote",
      request = "attach",
      connect = {
        host = "127.0.0.1",
        port = "43000"
      }
    },
  },
  delve = {
    port = "43000"
  },
}

Debug test + attach remote both work.

FWIW, this config works without the pkill hack: ``` require('dap-go').setup { dap_configurations = { { type = "go", name = "Attach remote", mode = "remote", request = "attach", connect = { host = "127.0.0.1", port = "43000" } }, }, delve = { port = "43000" }, } ``` Debug test + attach remote both work.

👍 2

leoluz commented

2023-09-11 04:31:56 +03:00

(Migrated from github.com)

I don't use the remote debug feature and I am not sure if there is still an issue with clashing dlv instances running in the same port or not.

Can someone please confirm so I can close this issue?

I don't use the remote debug feature and I am not sure if there is still an issue with clashing dlv instances running in the same port or not. Can someone please confirm so I can close this issue?

psethwick commented

2023-09-14 23:09:58 +03:00

(Migrated from github.com)

I haven't seen it, as one data point.

It wasn't a perfect test, but I just now started a remote and connected to it with htop open (filtered to 'dlv') and didn't see any extras pop up.

I haven't seen it, as one data point. It wasn't a perfect test, but I just now started a remote and connected to it with htop open (filtered to 'dlv') and didn't see any extras pop up.

stale[bot] commented

2024-03-13 09:36:01 +03:00

(Migrated from github.com)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

paulbrittain commented

2024-03-13 16:24:08 +03:00

(Migrated from github.com)

@psethwick 's config worked for me in-so-far as the connection was made to the remote Delve. However, the listener couldn't be started because the port is in use.

require('dap-go').setup {
  -- Additional dap configurations can be added.
  -- dap_configurations accepts a list of tables where each entry
  -- represents a dap configuration. For more details do:
  -- :help dap-configuration
  dap_configurations = {
    {
      -- Must be "go" or it will be ignored by the plugin
      type = "go",
      name = "Attach remote",
      mode = "remote",
      request = "attach",
    },
    {
      type = "go",
      name= "Service-1",
      request= "attach",
      mode= "remote",
    }
  },
  delve = {
      port = 45000,
  }
}

couldn't start listener: listen tcp 127.0.0.1:45000: bind: address already in use

I have a number of containerized Go services, and each can run delve on a diferent port. IDEs such as Vscode (config below) and Goland can attach to these processes

VSCode debug config:

"configurations": [
        {
            "name": "Service-1",
            "port": 45000,
            "type": "go",
            "request": "attach",
            "mode": "remote",
            "showLog": true,
            "trace": "log",
            "logOutput": "rpc"
        },
        {
            "name": "Service-2",
            "port": 35000,
            "type": "go",
            "request": "attach",
            "mode": "remote",
            "showLog": true,
            "trace": "log",
            "logOutput": "rpc"
        },
    ]

Ideally, the dap_configuration would handle different ports for different configuration entries too.

Any help welcome! If I get this working I'll be sure to report back here.

dap_configurations = {
 {
   -- Must be "go" or it will be ignored by the plugin
   type = "go",
   name = "Attach remote",
   mode = "remote",
   request = "attach",
 },
 {
   type = "go",
   name= "Service-1",
   port= 45000,
   request= "attach",
   mode= "remote",
 },
 {
   type = "go",
   name= "Service-2",
   --port= 35000,
   request= "attach",
   mode= "remote",
   port = "35000"
 }
},
}

@psethwick 's config worked for me in-so-far as the connection was made to the remote Delve. However, the listener couldn't be started because the port is in use. ``` require('dap-go').setup { -- Additional dap configurations can be added. -- dap_configurations accepts a list of tables where each entry -- represents a dap configuration. For more details do: -- :help dap-configuration dap_configurations = { { -- Must be "go" or it will be ignored by the plugin type = "go", name = "Attach remote", mode = "remote", request = "attach", }, { type = "go", name= "Service-1", request= "attach", mode= "remote", } }, delve = { port = 45000, } } ``` `couldn't start listener: listen tcp 127.0.0.1:45000: bind: address already in use` I have a number of containerized Go services, and each can run delve on a diferent port. IDEs such as Vscode (config below) and Goland can attach to these processes VSCode debug config: ``` "configurations": [ { "name": "Service-1", "port": 45000, "type": "go", "request": "attach", "mode": "remote", "showLog": true, "trace": "log", "logOutput": "rpc" }, { "name": "Service-2", "port": 35000, "type": "go", "request": "attach", "mode": "remote", "showLog": true, "trace": "log", "logOutput": "rpc" }, ] ``` Ideally, the dap_configuration would handle different ports for different configuration entries too. Any help welcome! If I get this working I'll be sure to report back here. ``` dap_configurations = { { -- Must be "go" or it will be ignored by the plugin type = "go", name = "Attach remote", mode = "remote", request = "attach", }, { type = "go", name= "Service-1", port= 45000, request= "attach", mode= "remote", }, { type = "go", name= "Service-2", --port= 35000, request= "attach", mode= "remote", port = "35000" } }, } ```

👍 2

leoluz commented

2024-03-25 04:42:39 +03:00

(Migrated from github.com)

@paulbrittain Thank you for your investigation. I am closing this for now. Please feel free to reopen if the issue persists.

stevenctl commented

2024-05-28 20:34:23 +03:00

(Migrated from github.com)

fwiw I'm getting the exact same issue. seems like somehow the plugin is both trying to attach and start it's own headless dlv process?

When I attach I get a warning that dlv exited with code 1 but the UI and logs from my debug process show that I'm attached. Breakpoints do not pause, the repl doesn't give any accurate info.

fwiw I'm getting the exact same issue. seems like somehow the plugin is both trying to attach _and_ start it's own headless dlv process? When I attach I get a warning that `dlv exited with code 1` but the UI and logs from my debug process show that I'm attached. Breakpoints do not pause, the repl doesn't give any accurate info.

👍 3

jsternberg commented

2024-06-25 04:27:21 +03:00

(Migrated from github.com)

@stevenctl I'm running into the same issue. I was able to track it down to likely this commit: leoluz/nvim-dap-go@bd9823da22

There was a custom delve adapter with a callback and it started using the builtin nvim-dap adapter, but the nvim-dap adapter doesn't seem to look at the request type before it determines what it does. I tracked it to this call here. It calls attach which I thought was a strange name, but this then calls connect here and the connect method seems to always launch the executable if the executable is set.

The only way I can see to fix it is to use the enrich_config to exclude the executable when the request is attach in this plugin or potentially modify this in nvim-dap.

I just started using nvim maybe last week though so I'm not sure where to make the change upstream or how to modify this locally. @leoluz I'd like to make a PR for this if I can get some guidance on where the change should be made. I use remote debugging pretty frequently by attaching to a delve server inside of a docker container.

@stevenctl I'm running into the same issue. I was able to track it down to likely this commit: https://github.com/leoluz/nvim-dap-go/commit/bd9823da22165ea4aa7ec232e8c3a9b3158e017a There was a custom delve adapter with a callback and it started using the builtin `nvim-dap` adapter, but the `nvim-dap` adapter doesn't seem to look at the `request` type before it determines what it does. I tracked it to this call [here](https://github.com/mfussenegger/nvim-dap/blob/6f79b822997f2e8a789c6034e147d42bc6706770/lua/dap.lua#L439). It calls `attach` which I thought was a strange name, but this then calls `connect` [here](https://github.com/mfussenegger/nvim-dap/blob/6f79b822997f2e8a789c6034e147d42bc6706770/lua/dap/session.lua#L1300) and the connect method seems to always launch the executable if the executable is set. The only way I can see to fix it is to use the `enrich_config` to exclude the executable when the request is `attach` in this plugin or potentially modify this in `nvim-dap`. I just started using nvim maybe last week though so I'm not sure where to make the change upstream or how to modify this locally. @leoluz I'd like to make a PR for this if I can get some guidance on where the change should be made. I use remote debugging pretty frequently by attaching to a delve server inside of a docker container.

Rows
Columns

Cannot to attach the remote dlv process #35