[BUG] Attaching to running instance doesn't work (fzf-lua) #45

kapral18 · 2024-05-19T14:26:10Z

I am using LazyVim which uses this setup https://github.com/LazyVim/LazyVim/blob/ad22adab7d446018875de2dc96168295cad9298e/lua/lazyvim/plugins/extras/dap/nlua.lua#L31

Here is my config on top:
https://github.com/kapral18/dotfiles/blob/ad539b7b57222293fdcae58fa2dde498789a34dd/home/dot_config/exact_nvim/exact_lua/exact_plugins/osv.lua

Initially I spotted the issue when trying to debug plugins inside lazy.nvim plugin folder, but to showcase the gist of it a simplified example will do as well.

I create main.lua:

local function test()
	print(1)
	print(2)
	print(3)
	print(4)
	print(5)
	print(6)
end

vim.keymap.set("n", "<Space>0", test, { buffer = true })

I run F5 from my config and see Server started on port 8086.
I open a second nvim instance with the same file, and set breakpoint on line 3 (with print(2)).
Call nvim-dap continue and attach to 8086
I see the message "Running: Attach to running Neovim instance" but couple of seconds later got a message about debug adapter not responding
I switch to debugee instance and run the file to make sure keymap is registered with :luafile %
I try the keymap and only see printed number in debuggee. Debugger doesn't respond.
I exit debuggee instance and the debugger suddenly pops up the dap widget UI

But at no point the breakpoint is caught.

The text was updated successfully, but these errors were encountered:

jbyuki · 2024-05-20T15:59:32Z

Thank you for opening an issue.

At first glance, I don't see what is wrong. The steps (which are nicely explained) seem to be correct.

Could you try launching the server with logging enabled. This would translate to changing the following line in your config.
It boils down to the addition of log = true to launch.

keys = {
    { "<F5>", [[:lua require"osv".launch({port = 8086, log=true})<CR>]], desc = "Launch OSV", noremap = true },
  },

This should output a log file within the nvim-data folder which can be found by running :echo stdpath('data'), it should be named osv.log. Please see there and post it if it can help.

kapral18 · 2024-05-20T23:14:48Z

@jbyuki

After I invoked with logs and terminated debuggee I get this osv.log:

{
  event = "terminated",
  seq = 1,
  type = "event"
}
{
  body = {
    exitCode = 0
  },
  event = "exited",
  seq = 2,
  type = "event"
}
{
  arguments = {
    adapterID = "nvim-dap",
    clientID = "neovim",
    clientName = "neovim",
    columnsStartAt1 = true,
    linesStartAt1 = true,
    locale = "en_US.UTF-8",
    pathFormat = "path",
    supportsProgressReporting = true,
    supportsRunInTerminalRequest = true,
    supportsStartDebuggingRequest = true,
    supportsVariableType = true
  },
  command = "initialize",
  seq = 1,
  type = "request"
}

jbyuki · 2024-05-21T19:58:16Z

I still cannot pinpoint what is going on. I should have asked ealier but could you log nvim-dap as well?

https://github.com/mfussenegger/nvim-dap/blob/5a2f7121869394502521c52b2bc581ab22c69447/doc/dap.txt#L984-L1005

Maybe something to try would be to change the port. It may be a port blocking issue although I doubt it.
Also make sure to update the plugins. And what is your OS/nvim version?

jbyuki · 2024-05-21T20:15:54Z

It would be awesome if you could log osv again. I just added a new commit to make a more exhaustive log.

kapral18 · 2024-05-22T10:04:23Z

MacOS Sonoma 14.5

NVIM v0.10.0
Build type: Release
LuaJIT 2.1.1713773202
Run "nvim -V1 -v" for more info

For some reason I didn't get any dap.log after setting the log to trace.

osv.log

{
  event = "terminated",
  seq = 1,
  type = "event"
}
{
  body = {
    exitCode = 0
  },
  event = "exited",
  seq = 2,
  type = "event"
}
{
  arguments = {
    adapterID = "nvim-dap",
    clientID = "neovim",
    clientName = "neovim",
    columnsStartAt1 = true,
    linesStartAt1 = true,
    locale = "en_US.UTF-8",
    pathFormat = "path",
    supportsProgressReporting = true,
    supportsRunInTerminalRequest = true,
    supportsStartDebuggingRequest = true,
    supportsVariableType = true
  },
  command = "initialize",
  seq = 1,
  type = "request"
}
{
  arguments = {
    adapterID = "nvim-dap",
    clientID = "neovim",
    clientName = "neovim",
    columnsStartAt1 = true,
    linesStartAt1 = true,
    locale = "en_US.UTF-8",
    pathFormat = "path",
    supportsProgressReporting = true,
    supportsRunInTerminalRequest = true,
    supportsStartDebuggingRequest = true,
    supportsVariableType = true
  },
  command = "initialize",
  seq = 1,
  type = "request"
}
{
  body = {
    supportTerminateDebuggee = true,
    supportsConditionalBreakpoints = true,
    supportsHitConditionalBreakpoints = true,
    supportsSetVariable = true
  },
  command = "initialize",
  request_seq = 1,
  seq = 1,
  success = true,
  type = "response"
}
{
  event = "initialized",
  seq = 2,
  type = "event"
}

jbyuki · 2024-05-22T10:15:44Z

I will get back later but make sure to check
vim.fn.stdpath('cache'). It is not the same folder as the one used by osv, it should be there.

kapral18 · 2024-05-22T11:21:59Z

you are right my bad

here is the file


[ INFO ] 2024-05-19T01:52:10Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ INFO ] 2024-05-19T01:53:00Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ INFO ] 2024-05-19T01:54:09Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ INFO ] 2024-05-19T01:55:30Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ INFO ] 2024-05-19T01:56:02Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ INFO ] 2024-05-19T01:56:03Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ INFO ] 2024-05-19T01:56:05Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"


[ INFO ] 2024-05-19T02:20:18Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ ERROR ] 2024-05-19T02:20:44Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:965 ]	"No callback found. Did the debug adapter send duplicate responses?"	{
  body = {
    supportTerminateDebuggee = true,
    supportsConditionalBreakpoints = true,
    supportsHitConditionalBreakpoints = true,
    supportsSetVariable = true
  },
  command = "initialize",
  request_seq = 1,
  seq = 3,
  success = true,
  type = "response"
}

[ INFO ] 2024-05-19T02:26:47Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"

[ INFO ] 2024-05-19T02:57:52Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ INFO ] 2024-05-19T02:58:20Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ INFO ] 2024-05-19T02:58:23Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ INFO ] 2024-05-19T02:59:44Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"




[ INFO ] 2024-05-19T16:20:02Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ INFO ] 2024-05-19T16:23:03Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"
[ ERROR ] 2024-05-19T16:23:21Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:965 ]	"No callback found. Did the debug adapter send duplicate responses?"	{
  body = {
    supportTerminateDebuggee = true,
    supportsConditionalBreakpoints = true,
    supportsHitConditionalBreakpoints = true,
    supportsSetVariable = true
  },
  command = "initialize",
  request_seq = 1,
  seq = 3,
  success = true,
  type = "response"
}
[ ERROR ] 2024-05-19T16:23:21Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:965 ]	"No callback found. Did the debug adapter send duplicate responses?"	{
  body = {
    supportTerminateDebuggee = true,
    supportsConditionalBreakpoints = true,
    supportsHitConditionalBreakpoints = true,
    supportsSetVariable = true
  },
  command = "initialize",
  request_seq = 1,
  seq = 5,
  success = true,
  type = "response"
}



[ INFO ] 2024-05-22T12:01:03Z+0200 ] ...al18/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1812 ]	"Session closed due to disconnect"

jbyuki · 2024-05-22T18:51:24Z

Would running this help before running launch().

:lua require"osv".stop = function() end

Then execute launch and the rest. This should avoid the early exit which is happening for some reason.

jbyuki · 2024-05-22T19:10:12Z

I just had a look in the config you linked. From the look of it, there is a substantial amount of plugin installed. I wouldn't be suprised if something is interacting together with osv in a bad way. The best would be to disable all plugins except a few ones and try. Thus by successive disabling/enabling, you could pinpoint what is going wrong. This is a standard practice for debugging plugins. The plugin osv is supposed to work with nvim-dap.

Another possibility is the OS which I cannot test right now.

kapral18 · 2024-05-22T19:14:16Z

Would running this help before running launch().
:lua require"osv".stop = function() end
Then execute launch and the rest. This should avoid the early exit which is happening for some reason.

this didn't work

kapral18 · 2024-05-22T19:14:37Z

I just had a look in the config you linked. From the look of it, there is a substantial amount of plugin installed. I wouldn't be suprised if something is interacting together with osv in a bad way. The best would be to disable all plugins except a few ones and try. Thus by successive disabling/enabling, you could pinpoint what is going wrong. This is a standard practice for debugging plugins. The plugin osv is supposed to work with nvim-dap.

Another possibility is the OS which I cannot test right now.

I will check with vanilla lazyvim starter then

kapral18 · 2024-05-22T20:33:48Z

Ok I checked. It wasn't lazyvim, not lazyvim-starter. But I found the issue the issue is this call https://github.com/kapral18/dotfiles/blob/ad539b7b57222293fdcae58fa2dde498789a34dd/home/dot_config/exact_nvim/exact_lua/exact_plugins/fzf.lua#L339

and I mean just the require, not the references, because I commented all them out and it hangs precisely on this require call. Something apparently happens inside fzf-lua actions that causes the osv to hang.

Not sure but maybe @ibhagwan has an idea?

jbyuki · 2024-05-22T20:50:44Z

Interesting. It was not known that fzf-lua had issues with osv

The problem is that probably someone needs to know the inner workings of both osv and fzf-lua which is most likely an empty set right now.

I don't follow how you pinpointed the error but it would be nice to pinpoint it further. So the require means it's inside this file actions.lua of fzf-lua when it's first executed. Which could be inside the utils.lua which is in turn required, possibly.

ibhagwan · 2024-05-22T21:08:52Z

The only thing I can think of is the overload of the require method in headless instances as part of the fzf-lua libuv command proxy.

https://github.com/ibhagwan/fzf-lua/blob/e65b86532380c4e60490bc19b647d0c4faa58096/lua/fzf-lua/libuv.lua#L16

It is possible that since you’re loading fzf-lua.actions file directly the global fzf directory var isn’t being set causing libuv to think it’s running the command wrapper.

You can try changing the actions require to require'fzf.lua'.actions (so the code calls init.lua first) or just add require'fzf.lua' in the line above the line you linked?

kapral18 · 2024-05-23T06:54:11Z

hey @ibhagwan you absolutely hit the nail on the head, I can confirm that with require'fzf-lua'.actions it works again

ibhagwan · 2024-05-23T09:56:38Z

hey @ibhagwan you absolutely hit the nail on the head, I can confirm that with require'fzf-lua'.actions it works again

Great!

I think I might add a global so this doesn’t happen even in this extreme edge cases.

jbyuki · 2024-05-23T16:43:47Z

@ibhagwan Thanks for the input! Glad this was sorted out. I will add a small note in the readme in case someone has the same issue.

@kapral18 I will close this issue now as it looks solved.

ibhagwan · 2024-05-23T16:52:45Z

Tysm @jbyuki! And ty @kapral18 for great debugging.

jbyuki changed the title ~~[BUG] Attaching to running instance doesn't work~~ [BUG] Attaching to running instance doesn't work (LazyVim/MacOS) May 22, 2024

jbyuki changed the title ~~[BUG] Attaching to running instance doesn't work (LazyVim/MacOS)~~ [BUG] Attaching to running instance doesn't work (fzf-lua) May 22, 2024

jbyuki closed this as completed May 23, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG] Attaching to running instance doesn't work (fzf-lua) #45

[BUG] Attaching to running instance doesn't work (fzf-lua) #45

kapral18 commented May 19, 2024 •

edited

Loading

jbyuki commented May 20, 2024 •

edited

Loading

kapral18 commented May 20, 2024

jbyuki commented May 21, 2024

jbyuki commented May 21, 2024

kapral18 commented May 22, 2024 •

edited

Loading

jbyuki commented May 22, 2024

kapral18 commented May 22, 2024

jbyuki commented May 22, 2024

jbyuki commented May 22, 2024 •

edited

Loading

kapral18 commented May 22, 2024

kapral18 commented May 22, 2024

kapral18 commented May 22, 2024 •

edited

Loading

jbyuki commented May 22, 2024

ibhagwan commented May 22, 2024

kapral18 commented May 23, 2024

ibhagwan commented May 23, 2024

jbyuki commented May 23, 2024

ibhagwan commented May 23, 2024

[BUG] Attaching to running instance doesn't work (fzf-lua) #45

[BUG] Attaching to running instance doesn't work (fzf-lua) #45

Comments

kapral18 commented May 19, 2024 • edited Loading

jbyuki commented May 20, 2024 • edited Loading

kapral18 commented May 20, 2024

jbyuki commented May 21, 2024

jbyuki commented May 21, 2024

kapral18 commented May 22, 2024 • edited Loading

jbyuki commented May 22, 2024

kapral18 commented May 22, 2024

jbyuki commented May 22, 2024

jbyuki commented May 22, 2024 • edited Loading

kapral18 commented May 22, 2024

kapral18 commented May 22, 2024

kapral18 commented May 22, 2024 • edited Loading

jbyuki commented May 22, 2024

ibhagwan commented May 22, 2024

kapral18 commented May 23, 2024

ibhagwan commented May 23, 2024

jbyuki commented May 23, 2024

ibhagwan commented May 23, 2024

kapral18 commented May 19, 2024 •

edited

Loading

jbyuki commented May 20, 2024 •

edited

Loading

kapral18 commented May 22, 2024 •

edited

Loading

jbyuki commented May 22, 2024 •

edited

Loading

kapral18 commented May 22, 2024 •

edited

Loading