bug: cannot use `dap.up()` after jumping to frame from threads view

[przepompownia]

Did you check docs and existing issues?

• I have read all the plugin docs
• I have searched the existing issues
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

v0.12.0-dev-347+gbee45fc0e7

Operating system/version

Debian Sid

Describe the bug

E5108: Lua: ...onfig/nvim/pack/plugins/opt/nvim-dap/lua/dap/session.lua:2000: id of current frame must be present in frames
stack traceback:
	[C]: in function 'assert'
	...onfig/nvim/pack/plugins/opt/nvim-dap/lua/dap/session.lua:2000: in function '_frame_delta'
	...rctgx/.config/nvim/pack/plugins/opt/nvim-dap/lua/dap.lua:901: in function 'up'
	[string ":lua"]:1: in main chunk

I get it with the below steps.

Steps To Reproduce

1. stop the adapter on some breakpoint
2. open threads section and jump to some not current frame by <CR>
3. call :lua require'dap'.up()

Expected Behavior

:lua require'dap'.up() works in such repro.

[igorlfs]

Can you provide more details? Most importantly the adapter, given that, for instance, I can't reproduce with debugpy. If you share minimal files, this would also be nice.

[przepompownia]

In short I get it with PHP adapter. An example may require modification of some existing project created because of dap-ui issues years ago.

https://github.com/przepompownia/dap-view-repro - that's it. Give me know if you cannot start it.

[igorlfs]

Upon further inspection, I can actually reproduce with debugpy.

Indeed, this seems to be either a limitation with the protocol itself or with nvim-dap.

nvim-dap manipulates the frames only in the stopped thread. Using its threads widget, it's also possible to trigger the same exact error, with the same reproduction steps

Can you open an issue upstream? I'm not sure if the client should have the ability to change threads like this (since a thread may not be stopped, the frames may not be up-to-date, which could lead to confusion).

[przepompownia]

Can you open an issue upstream? I'm not sure if the client should have the ability to change threads like this (since a thread may not be stopped, the frames may not be up-to-date, which could lead to confusion).

Rather not in nearest days. Before that I'd like to check how nvim-dap-ui deals with it (I found a while at least for switching to nvim-dap-ui: there is no such error).

[Seblerr]

Hello, loving this plugin! I have the same issue, but with cpptools. Can also confirm that it works with dap-ui.

In addition, it would be great to to have the current frame highlighted in the Threads view. Especially after using dap.up(), it's very easy to get lost.

[przepompownia]

Sorry, I needed to find time to compare all the three projects.

I cannot reproduce this nonexistent frame id error on nvim-dap's builtin widget (:lua local widgets = require('dap.ui.widgets'); widgets.sidebar(widgets.frames).open()): after jumping from that UI frame element I can still jump up() and down().

@igorlfs are you sure that the frames kept in dap-view.state are up to date?

In my case, the frame from dap-view had id 13, while frames available to nvim-dap had ids from 1 to 12. The trivial case of subsequent jumping only to the first (current) frame in 12-frames thread shows id 13, 25, 37, 49, ...

https://github.com/mfussenegger/nvim-dap/blob/40a8189b8a57664a1850b0823fdcb3ac95b9f635/lua/dap/ui/widgets.lua#L264-L293

[igorlfs]

Hey folks,

Hello, loving this plugin!

Thanks!

I have the same issue, but with cpptools. Can also confirm that it works with dap-ui.

Yeah, it's definitely not adapter-related. I haven't had the time to properly study how dap-ui handles this scenario, but I suspect it has something to do with the following lines:

https://github.com/rcarriga/nvim-dap-ui/blob/73a26abf4941aa27da59820fd6b028ebcdbcf932/lua/dapui/client/lib.lua#L50-L52

If so, I have to wonder: is it actually switching the frame? It must be doing something under the hood (dap-ui has a custom SessionProxy that I have no idea how it's supposed to work), because something is going on with the default _frame_set function (more on that later).

Sorry, I needed to find time to compare all the three projects.

No worries!

I cannot reproduce this nonexistent frame id error on nvim-dap's builtin widget

Check this out:

dap-threads-frames.mp4

Here I call both dap.up() and dap.down() (with keybindings) after switching the thread.

@igorlfs are you sure that the frames kept in dap-view.state are up to date?

They could be out of sync, but I believe the issue is something else, which I mentioned in the other comment:

nvim-dap manipulates the frames only in the stopped thread.

Perhaps the stopped_thread_id is not being updated somehow? Do notice that I'm using

        require("dap").defaults.fallback.auto_continue_if_many_stopped = false

To pause all threads (which might be the reason you couldn't reproduce). Here's the file I'm using, if you wanna give it a go.

In addition, it would be great to to have the current frame highlighted in the Threads view.

Noted, will do.

---

Sorry for the lengthy comment. The next step to fix this issue remains the same as before: it should be reported to nvim-dap. If a fix is made upstream, but the problem persists, we can look further into investigating the possibly outdated frame IDs.

[igorlfs]

after jumping from that UI frame element

I was under the impression that switching to another thread was a necessary step to repro. We may be talking about different issues, it seems. I haven't run into any issues switching frames within the same thread.

@Seblerr can you share a sample setup? A minimal (C++) file, a DAP configuration and the like (just because it's easier for me to work with C++ compared to PHP)

[igorlfs]

In addition, it would be great to to have the current frame highlighted in the Threads view. Especially after using dap.up(), it's very easy to get lost.

Done in 0e41468, let me know if you encounter any issues.

[przepompownia]

I still get this bug on the repro even with 0e41468

[Seblerr]

Hi,

Sorry, I missed your previous message. I just tested with the new commit, but I can't tell any difference from before. If I hit a breakpoint, the top line in Threads view is highlighted. If I press dap.up(), the highlight will move down a row, which is correct, but if I do dap.down() afterwards to go back to my breakpoint, the highlight will move down a row again, instead of going up. I hope that makes some sense.

Just to be clear, this is a different issue than not being able to use dap.up() at all, this is just that the current frame is not correctly highlighted in the Threads view, which still seems to be the case after 0e41468.

[igorlfs]

I still get this bug on the repro even with 0e41468

My goal was to address @Seblerr's comment, I still haven't figured out a reliable repro for the actual issue itself, so I haven't come up with any solutions yet.

If I hit a breakpoint, the top line in Threads view is highlighted. If I press dap.up(), the highlight will move down a row, which is correct, but if I do dap.down() afterwards to go back to my breakpoint, the highlight will move down a row again, instead of going up. I hope that makes some sense.

Can you please share a repro? A C++ file and your dap configuration?

By the way, both of you could try #77. I highly doubt it would be a fix in its current stage, but worth a shot anyway.