Skip to content
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

fix: do not add executable to adapter in launch request #91

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jsternberg
Copy link

The adapter would add the executable property to the adapter regardless of whether the request was launch or attach. When attach was used, it would attempt to start dlv on the same port that it was attempting to configure.

This changes it so the executable is not added if attach is used and adds some protection code to prevent the random port assignment from being used with the attach configuration (where it wouldn't work anyway).

Fixes issue mentioned here: #35 (comment)
Solution suggested here: mfussenegger/nvim-dap#1273 (comment)

@jsternberg jsternberg force-pushed the remove-executable-for-attach branch 2 times, most recently from 4d6cc50 to 6be7e01 Compare June 26, 2024 17:28
@leoluz
Copy link
Owner

leoluz commented Jul 4, 2024

@jsternberg Tks for your PR. I'll try to find time to review it in the coming days.

@leoluz leoluz self-requested a review July 20, 2024 02:08
@leoluz
Copy link
Owner

leoluz commented Jul 20, 2024

@jsternberg I am concluding a review in another PR (#78) that will probably cause some conflicts with the code implemented in this one. I'll let you know when that gets merged.

@leoluz
Copy link
Owner

leoluz commented Aug 6, 2024

@jsternberg #78 is merged. Can you please rebase?

@jsternberg
Copy link
Author

I'll probably have time to rebase this sometime this week.

This prevents the executable from being added to the adapter when remote
mode is used. This allows the plugin to attach to already running
instances that are run through `dlv exec` to perform remote debugging.
@jsternberg
Copy link
Author

On vacation and can't really test it that well right now, but I wanted to try and update the PR. The intention is that mode = remote is used if you've launched the program through dlv exec and want to attach to it through that method.

@wilriker
Copy link

I encountered the same issue yesterday (and it took me about all day to figure out a working solution - only found this PR this morning when wanting to create my own PR).

I have a working version based on latest main branch. Should I provide it as a separate PR? Otherwise: the implementation of setup_delve_adapter has changed into:

local function setup_delve_adapter(dap, config)
  local args = { "dap", "-l", "127.0.0.1:" .. config.delve.port }
  vim.list_extend(args, config.delve.args)

  dap.adapters.go = function(callback, client_config)
    local delve_config = {
      type = "server",
      port = config.delve.port,
      executable = {
        command = config.delve.path,
        args = args,
        detached = config.delve.detached,
        cwd = config.delve.cwd,
      },
      options = {
        initialize_timeout_sec = config.delve.initialize_timeout_sec,
      },
    }
    if client_config.port == nil then
      callback(delve_config)
      return
    end

    local host = client_config.host
    if host == nil then
      host = "127.0.0.1"
    end

    local listener_addr = host .. ":" .. client_config.port
    delve_config.port = client_config.port

    if client_config.request == "attach" and client_config.mode == "remote" then
      -- if we want to attach to an existing debugger only we have to remove the executable section
      -- otherwise nvim-dap will try to start a new debugger at the same port and fails (since port is already bound)
      client_config.executable = nil
    else
      delve_config.executable.args = { "dap", "-l", listener_addr }
    end

    callback(delve_config)
  end
end

@jsternberg
Copy link
Author

I'm back from vacation so I can probably test out my own change today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants