The "remote" example from the README doesn't appear to work #105

New issue

Closed

opened 2024-12-09 17:16:04 +03:00 by aktau · 5 comments

aktau commented

2024-12-09 17:16:04 +03:00

(Migrated from github.com)

From the README:

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

So I tried to connect to a running dlv dap, and it connects alright (after I hard-code the port), but then immediately I get that dlv exits with code 1. After reading nvim-dap docs, I figure this is due to the following: leoluz/nvim-dap-go@6aa88167ea/lua/dap-go.lua (L69-L81).

As it turns out, if an executable attribute is set, mfussenegger/nvim-dap will spawn that executable, even when request = "attach". This is incognruent with mode = "remote". Docs: mfussenegger/nvim-dap@580d6e5263/doc/dap.txt (L76-L78).

So I fixed my problem by commenting out that executable section. It'd probably make sense to make this executable section depend on whether or not mode == "remote".

From the README: ```lua lua require('dap-go').setup { dap_configurations = { { type = "go", name = "Attach remote", mode = "remote", request = "attach", }, }, } ``` So I tried to connect to a running `dlv dap`, and it connects alright (after I hard-code the port), but then immediately I get that `dlv exits with code 1`. After reading `nvim-dap` docs, I figure this is due to the following: https://github.com/leoluz/nvim-dap-go/blob/6aa88167ea1224bcef578e8c7160fe8afbb44848/lua/dap-go.lua#L69-L81. As it turns out, if an `executable` attribute is set, `mfussenegger/nvim-dap` will spawn that executable, even when `request = "attach"`. This is incognruent with `mode = "remote"`. Docs: https://github.com/mfussenegger/nvim-dap/blob/580d6e526358afd0e4bba053e68fd59cf581a161/doc/dap.txt#L76-L78. So I fixed my problem by commenting out that `executable` section. It'd probably make sense to make this `executable` section depend on whether or not `mode == "remote"`.

👍 1

nalum commented

2025-02-11 12:41:42 +03:00

(Migrated from github.com)

I've opened an PR to fix this, just waiting for review and merge.

#106

I've opened an PR to fix this, just waiting for review and merge. - #106

dennypenta commented

2025-02-13 12:51:51 +03:00

(Migrated from github.com)

I think think it's related, but I struggle to connect to a debugger server in general.
I try config:

    {
      "type": "go",
      "name": "debug remote service",
      "mode": "remote",
      "request": "attach",
      "port": 40000,
      "host": "localhost"
    },

and it gives me "Failed to attach: no debugger found".
I tried the branch of @Nalum, didn't work for me.
I guess I just have a wrong config, right?
the dap port is exposed from a local docker image, I can connect from jetbrains, so the debugger server itself is correct for sure.

I think think it's related, but I struggle to connect to a debugger server in general. I try config: ``` { "type": "go", "name": "debug remote service", "mode": "remote", "request": "attach", "port": 40000, "host": "localhost" }, ``` and it gives me "Failed to attach: no debugger found". I tried the branch of @Nalum, didn't work for me. I guess I just have a wrong config, right? the dap port is exposed from a local docker image, I can connect from jetbrains, so the debugger server itself is correct for sure.

👍 1

dennypenta commented

2025-02-13 14:35:29 +03:00

(Migrated from github.com)

I found an issue, the port value is ignored from vscode config and is taken from dap.adapters.go

I found an issue, the port value is ignored from vscode config and is taken from `dap.adapters.go`

stale[bot] commented

2025-08-12 14:59:38 +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.

Luks17 commented

2025-10-13 06:23:18 +03:00

(Migrated from github.com)

I can confirm this problem is still happening, I think this issue should be reopened.

Meanwhile I'm using @nalum solution which works great.

I can confirm this problem is still happening, I think this issue should be reopened. Meanwhile I'm using @nalum solution which works great.

❤️ 1