Frames for pre-compiled sources report wrong path/line/column

[mfussenegger]

Neovim pre-compiles a couple of it's modules. See https://github.com/neovim/neovim/blob/0fe0cf5adaab06b92250eb350306de63c4d4f36f/CONTRIBUTING.md?plain=1#L259-L268

If you try to step into a function that's defined in such a pre-compiled module like vim.validate (https://github.com/neovim/neovim/blob/0fe0cf5adaab06b92250eb350306de63c4d4f36f/runtime/lua/vim/shared.lua#L849-L854), the debug adapter reports frames like:

stackFrames = { {
    column = 0,
    id = 31,
    line = 0,
    name = "validate",
    source = {
      name = "@vim/shared.lua",
      path = "/path/to/dev/project/a/vim/shared.lua"
    }
  }, {

/project/a is not the folder containing neovim, but a different project I was debugging. It looks like it resolves this as relative path against the working directory?

These frames currently lead to two errors with nvim-dap:

• Vim:E474: Invalid argument
• Debug adapter reported a frame at line 0 column 1, but: Cursor position outside buffer. Ensure executable is up2date and if using a source mapping ensure it is correct

The first is because it tries to place a sign at line 0. The second because it tries to jump to its position. Neither works in an empty document. (Signs are 1 based, and nvim-dap sets linesStartAt1 = true, so 0 is invalid anyways)

The specification says 0 line should be ignored, but under the condition that the source attribute is missing:

https://microsoft.github.io/debug-adapter-protocol/specification#Types_StackFrame

  /**
   * The line within the source of the frame. If the source attribute is missing
   * or doesn't exist, `line` is 0 and should be ignored by the client.
   */
  line: number;

So I'm a bit reluctant to simply ignore line=0 frames.

Is there a way osv could resolve the proper source, or maybe skip them?

[jbyuki]

Thank you for the issue, I made a small change to resolve the vim runtime directory. It reads into VIMRUNTIME and appends it to the path. This allows to step into vim internal functions as well.

What I was not sure is if all the vim internal scripts resides in VIMRUNTIME . At the moment, I cannot think of a case which would not work. But you probably know more about this.

Feel free to close this issue if you feel like it is solved.

[mfussenegger]

Thanks for looking into this.

The path is now resolved correctly, but column and line are still set to 0. Is it possible to change that as well?

[jbyuki]

For precompiled lua files my initial thought is that it's impossible to get the line number. At least not using debug.getinfo. It would be nice to get it another way but my initial assumption is that this information is lost.

The new behaviour is that such precompiled modules cannot be stepped into.

From my dev setups, on windows it can be stepped into (because it's not precompiled?) and linux cannot be stepped into.

[mfussenegger]

The new behaviour is that such precompiled modules cannot be stepped into.

Thanks, that's a nice improvement over the error messages.