Debug adpater reported a frame at line 74, cursor position outside buffer.

[akashdiphazra]

Debug adapter definition and debug configuration

C/C++ Debugger Doesn't exit properly.

local dap = require('dap')
dap.adapters.cppdbg = {
  id = 'cppdbg',
  type = 'executable',
  command = '/usr/local/nvim-dap-adapters/cpp-tools/extension/debugAdapters/bin/OpenDebugAD7',
}
dap.configurations.cpp = {
  {
    name = "vscode-cpptools",
    type = "cppdbg",
    request = "launch",
    program = function()
      return vim.fn.input('Path to executable: ', vim.fn.getcwd() .. '/', 'file')
    end,
    cwd = '${workspaceFolder}',
    launchCompleteCommand = "exec-run",
    stopAtEntry = false,
    miDebuggerArgs = "-x ./.gdbinit",
    setupCommands = {
      {
        text = '-enable-pretty-printing',
        description = 'enable pretty printing',
        ignoreFailures = false
      },
    },
  },
  {
    name = 'gdbserver',
    type = 'cppdbg',
    request = 'launch',
    MIMode = 'gdb',
    cwd = '${workspaceFolder}',
    miDebuggerPath = '/usr/bin/gdb',
    miDebuggerArgs = "-x ./.gdbinit",
    program = function()
      return vim.fn.input('Path to executable: ', vim.fn.getcwd() .. '/', 'file')
    end,
  },
}

Debug adapter version

0.6.0

Steps to Reproduce

Just step into the debugger until ends and the error appears.This problem basically appears while using vscode-cpptools extension.

Expected Result

Debugger should stop and exit.

Actual Result

Screencast from 2023-05-21 22-23-51_trimmed.webm

[mfussenegger]

Part of the idea behind reproduction steps is that one can follow them to reproduce the problem.

Could you please provide a short code snippet, the steps you used to compile it and logs?

And also minimize your config. Does the same issue occur without stuff like miDebuggerArgs = "-x ./.gdbinit", ? If not, you'll also have to provide your gdbinit.

This is likely a debug-adapter/configuration problem, as the message already indicates.

[akashdiphazra]

I tried to skip stl and other .h files , so that it's doesn't step into unnecessary implementation, It's disturbing and overwhelming during debugging process because unnecessary files open randomly. Unlike vscode and visual studio debugger JusMyCode feature doesn't work well, I think it's still not fully implemented yet even on windows also , it tried many times but failed. So the last option was using .gdbinit file.

my .gdbinit file

skip -gfi /usr/include/c++/12/*/*/*
skip -gfi /usr/include/c++/12/*/*
skip -gfi /usr/include/c++/12/*

Dap log file

[ ERROR ] 2023-05-24T18:19:38Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:1342 ]	"stderr"	{
  command = "/usr/local/nvim-dap-adapters/cpp-tools/extension/debugAdapters/bin/OpenDebugAD7",
  id = "cppdbg",
  type = "executable"
}	"waiting for v8 protocol on stdin/stdout\n"
[ INFO ] 2023-05-24T18:20:05Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:729 ]	"Telemetry"	"VS/Diagnostics/Debugger/Launch"


[ ERROR ] 2023-05-24T18:45:24Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:1342 ]	"stderr"	{
  command = "/usr/local/nvim-dap-adapters/cpp-tools/extension/debugAdapters/bin/OpenDebugAD7",
  id = "cppdbg",
  type = "executable"
}	"waiting for v8 protocol on stdin/stdout\n"
[ INFO ] 2023-05-24T18:45:34Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:729 ]	"Telemetry"	"VS/Diagnostics/Debugger/Launch"

[ ERROR ] 2023-05-24T18:52:20Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:1342 ]	"stderr"	{
  command = "/usr/local/nvim-dap-adapters/cpp-tools/extension/debugAdapters/bin/OpenDebugAD7",
  id = "cppdbg",
  type = "executable"
}	"waiting for v8 protocol on stdin/stdout\n"
[ INFO ] 2023-05-24T18:52:21Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:729 ]	"Telemetry"	"VS/Diagnostics/Debugger/Launch"

After removing miDebuggerArgs = "-x ./.gdbinit" same thing appears. Results of log file after removing that part.

[ ERROR ] 2023-05-24T18:19:38Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:1342 ]	"stderr"	{
  command = "/usr/local/nvim-dap-adapters/cpp-tools/extension/debugAdapters/bin/OpenDebugAD7",
  id = "cppdbg",
  type = "executable"
}	"waiting for v8 protocol on stdin/stdout\n"
[ INFO ] 2023-05-24T18:20:05Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:729 ]	"Telemetry"	"VS/Diagnostics/Debugger/Launch"


[ ERROR ] 2023-05-24T18:45:24Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:1342 ]	"stderr"	{
  command = "/usr/local/nvim-dap-adapters/cpp-tools/extension/debugAdapters/bin/OpenDebugAD7",
  id = "cppdbg",
  type = "executable"
}	"waiting for v8 protocol on stdin/stdout\n"
[ INFO ] 2023-05-24T18:45:34Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:729 ]	"Telemetry"	"VS/Diagnostics/Debugger/Launch"

[ ERROR ] 2023-05-24T18:52:20Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:1342 ]	"stderr"	{
  command = "/usr/local/nvim-dap-adapters/cpp-tools/extension/debugAdapters/bin/OpenDebugAD7",
  id = "cppdbg",
  type = "executable"
}	"waiting for v8 protocol on stdin/stdout\n"
[ INFO ] 2023-05-24T18:52:21Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:729 ]	"Telemetry"	"VS/Diagnostics/Debugger/Launch"
[ INFO ] 2023-05-24T18:53:46Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:729 ]	"Telemetry"	"VS/Diagnostics/Debugger/DebugCompleted"
[ INFO ] 2023-05-24T18:53:46Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:1695 ]	"Session closed due to disconnect"

[ ERROR ] 2023-05-24T18:54:35Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:1342 ]	"stderr"	{
  command = "/usr/local/nvim-dap-adapters/cpp-tools/extension/debugAdapters/bin/OpenDebugAD7",
  id = "cppdbg",
  type = "executable"
}	"waiting for v8 protocol on stdin/stdout\n"
[ INFO ] 2023-05-24T18:54:36Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:729 ]	"Telemetry"	"VS/Diagnostics/Debugger/Launch"
[ INFO ] 2023-05-24T18:55:18Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:729 ]	"Telemetry"	"VS/Diagnostics/Debugger/DebugCompleted"
[ INFO ] 2023-05-24T18:55:18Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:1695 ]	"Session closed due to disconnect"


[ ERROR ] 2023-05-24T18:55:55Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:1342 ]	"stderr"	{
  command = "/usr/local/nvim-dap-adapters/cpp-tools/extension/debugAdapters/bin/OpenDebugAD7",
  id = "cppdbg",
  type = "executable"
}	"waiting for v8 protocol on stdin/stdout\n"
[ INFO ] 2023-05-24T18:55:56Z+0530 ] ...lunarvim/site/pack/lazy/opt/nvim-dap/lua/dap/session.lua:729 ]	"Telemetry"	"VS/Diagnostics/Debugger/Launch"

my configuration remains same as provided above.

[akashdiphazra]

Screencast from 2023-05-24 19-18-56.webm

[nezos]

Same issue with codelldb installed.

Any C++ simple file:

set breakpoint run keep executing next line until end debugger enters dissasembly and the error appearing is the same as reported 2 weeks ago: "Debug adapter reported a frame at line .... Cursor outside buffer..."

After the error the source file is closed and neovim plugins become unresponsive. Only solution is to quit.

My config and a sample cpp file: debug.txt test.txt

[Aeceon]

I think the issue might be here in session.lua:

 function switchbuf_fn.uselast()
    if vim.bo[cur_buf].buftype == '' or vim.bo[cur_buf].filetype == filetype then
      api.nvim_win_set_buf(cur_win, bufnr)
      set_cursor(cur_win, line, column)
    else
      local win = vim.fn.win_getid(vim.fn.winnr('#'))
      api.nvim_win_set_buf(win, bufnr)
      set_cursor(win, line, column)
    end
return true

I believe the disassembly buffer is type nofile and is therefore going to the else branch when it shouldn't. If you haven't switched windows it probably won't cause issues, but if you have, the "Cursor outside buffer" error will occur.

I haven't tested it, but it looks like there might be another issue here if you switch between multiple windows. The call to "vim.fn.winnr('#')" will get the last accessed window, but couldn't this potentially be the wrong window? Especially if you use nvim-dap-ui.

[mfussenegger]

I'd still need minimal and complete reproduction steps. "Any c++ file" is not sufficient.

[nezos]

I'd still need minimal and complete reproduction steps. "Any c++ file" is not sufficient.

A test file could be (test.cpp):

#include <iostream>
#include <iomanip>
#include <ostream>

int main()
{
  float      testf{0.123456789012345678901234567890};
  double     testd{0.123456789012345678901234567890};
  long double test{0.123456789012345678901234567890};
  std::cout << std::fixed << std::setprecision(20) << test << std::endl;
  std::cout << std::fixed << std::setprecision(20) << testf << std::endl;
  std::cout << std::fixed << std::setprecision(20) << testd << std::endl;
  std::cout << std::numbers::pi << std::endl;

  return 0;
}

And the CMakeLists.txt

cmake_minimum_required(VERSION 3.25)  # CMake version check
project(my_example)               # Create project "simple_example"
set(CMAKE_CXX_STANDARD 20)            # Enable c++20 standard

# Add main.cpp file of project root directory as source file
set(SOURCE_FILES test.cpp)

# Add executable target with source files listed in SOURCE_FILES variable
add_executable(test ${SOURCE_FILES})

My neovim configuration: nvim-configuration.zip

And steps to reproduce:

1. Run nvim test.cpp
2. :CMakeGenerate
3. :CMakeBuild
4. Set a breakpoint at any line, e.g., line 15. (space+B for my config)
5. Press F7 to switch to debug mode windows arrangement
6. Continue debug
7. Breakpoint hits. Step over until the end of program (return 0)
8. Step over again to next line and it goes to dissasembly
9. Press again to go to next line and error message appears + nvim becomes unresponsive -> need to close everything and start over to use it.

[mfussenegger]

The zip file is empty (?) and this doesn't look minimal. Ideally it would be a simple file, some g++ command, and plain neovim with only nvim-dap required, to rule out that any other plugins are interferring somehow.

[akashdiphazra]

You could go and check my repo, I have open-sourced my config, I use lunarvim by the way

Dap Configs are in --> /lvim/after/plugin/dap/

[geo-ant]

I have the same problem (also using the cmake tools plugin as the poster above). I'd be willing to try to produce a minimal config, but I don't know how to use nvim-dap without the help of cmake tools. Can someone point me to somewhere I can see how to do that?

Also I think it's probably a cmake tools problem because debugging works when I use it for my rust code with a different plugin... I cannot be sure though.

[bret-walda]

I am getting the same error while doing this with rust This is my dap configuration

local dap = require('dap')
dap.adapters.codelldb = {
    type = 'server',
    port = "${port}",
    executable = {
        command = '/home/bret/Downloads/extension/adapter/codelldb',
        args = {"--port", "${port}"},
    },
}
dap.configurations.cpp = {
  {
    name = "Launch file",
    type = "codelldb",
    request = "launch",
    program = function()
        return vim.fn.input('Path to executable: ', vim.fn.getcwd()..'/', 'file')
    end,
    cwd = '${workspaceFolder}',
    stopOnEntry = false,
  },
}
dap.configurations.rust = dap.configurations.cpp

This is how you can reproduce the error

1. cargo new "your project name"
2. cd "your project name"
3. cd src
4. nvim main.rs
5. the main file consists of this code

fn patter(a: &mut i64) -> i64 {
-> B for _i in 1..10{
 *a +=1;
-> B println!("The value of a is {}",a);
}
return *a;
}

fn main(){
let mut x: i64 = 0;
pattern(&mut x);
}

6. the cargo run which builds and runs the code
7. then run the debugger provide the path to binary which is /target/debug/"name of your project"
8. The break points hit
9. step into first time
10. the code breaks into assembly and i get the above error.

the "- > B" this indicates where i put my breakpoints.

edit : sorry but i have tried editing the code so that it looks better but cant do it. edit : fixed it

[mfussenegger]

Your example works fine for me and doesn't produce any errors.

[bret-walda]

Your example works fine for me and doesn't produce any errors.

Would you be kind enough to check my dot files they are on my GitHub maybe I haven't configured nvim-dap correctly otherwise I will try again and post the screen recording of what happens in the morning I can't right now because of load shedding.

[bret-walda]

Your example works fine for me and doesn't produce any errors.

cut.webm

This is what i get i have just realized this that if i keep pressing F1 which is the key to step into the program techinically keeps debugging but you can see in the vid that the code turns into assembly but keeps running until it is done.

[Aeceon]

@bret-walda, if you try it without nvim-dap-ui, does the error still occur?

[bret-walda]

@bret-walda, if you try it without nvim-dap-ui, does the error still occur?

I haven't tried I will let you know in some time.

[bret-walda]

@bret-walda, if you try it without nvim-dap-ui, does the error still occur?

i just tried it without nvim-dap-ui i just didn't press the key to start it and added the break points stepped into it and it still happened. I don't know if i should uninstall nvim-dap-ui and try again but it did the same thing without nvim-dap-ui.

[mfussenegger]

Please try with a minimal config:

E.g.:

minimal.lua:

local dap = require("dap")
dap.adapters.codelldb = {
  type = 'server',
  port = "${port}",
  executable = {
    command = os.getenv("HOME") .. "/apps/codelldb/extension/adapter/codelldb",
    args = {"--port", "${port}"},
  }
}
dap.configurations.rust = {
  {
    name = "codelldb: Launch",
    type = "codelldb",
    request = "launch",
    program = function()
      return vim.fn.input({
        prompt = "Path to executable: ",
        default = vim.fn.getcwd() .. "/",
        completion = "file"
      })
    end,
    cwd = '${workspaceFolder}',
    args = {},
  },
}

And then start nvim with nvim -u ~/path/to/minimal.lua

[bret-walda]

Please try with a minimal config:

E.g.:

minimal.lua:

local dap = require("dap")
dap.adapters.codelldb = {
  type = 'server',
  port = "${port}",
  executable = {
    command = os.getenv("HOME") .. "/apps/codelldb/extension/adapter/codelldb",
    args = {"--port", "${port}"},
  }
}
dap.configurations.rust = {
  {
    name = "codelldb: Launch",
    type = "codelldb",
    request = "launch",
    program = function()
      return vim.fn.input({
        prompt = "Path to executable: ",
        default = vim.fn.getcwd() .. "/",
        completion = "file"
      })
    end,
    cwd = '${workspaceFolder}',
    args = {},
  },
}

And then start nvim with nvim -u ~/path/to/minimal.lua

Doesn't change anything but if i stepover instead of stepping in the code doesn't turn into assembly and the debugger runs fine until the control flow goes out of the breakpoints and into the main function and at that point the process exits with code 0.

[Enigama]

I have the same warning message each time I press step into, any suggestions how to solve it?

[bret-walda]

I have the same warning message each time I press step into, any suggestions how to solve it?

Try to stepover and see if that works else do what mfussenegger suggested but there is no clear solution yet

[Enigama]

I have the same warning message each time I press step into, any suggestions how to solve it?

Try to stepover and see if that works else do what mfussenegger suggested but there is no clear solution yet

What he had suggested?

[Parsifa1]

I found that if I turn off stopAtEntry, the whole dap can work normally, otherwise the cursor position outside buffer will appear someone have the same situation with me. It seems that there should not have a breakpoint on cpp-lib function

[BitInByte]

I'm running into the same problem with firefox adapter. Only with step into, stepover works fine.

[bogdan-nikitin]

I have the same problem with C++ and lldb-vscode. Minimal init.lua:

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    "--branch=stable", -- latest stable release
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
{
    "mfussenegger/nvim-dap",
    config = function() 
        local dap = require('dap')
        dap.adapters.lldb = {
            type = 'executable',
            command = '/sbin/lldb-vscode',  --Change to your path
            name = 'lldb',
        }

        dap.configurations.cpp = {
          {
            name = "Launch file",
            type = "lldb",
            request = "launch",
            program = function()
              return vim.fn.input('Path to executable: ', vim.fn.getcwd() .. '/', 'file')
            end,
            cwd = '${workspaceFolder}',
            stopOnEntry = false,
          },
        }

        vim.keymap.set('n', '<F5>', require 'dap'.continue)
        vim.keymap.set('n', '<F9>', require 'dap'.step_into)
    end
}
})

Steps to reproduce almost the same problem:

1. nvim main.cpp
2. Paste next code:

int main() {
  // breakpoint here
}

3. Compile running :!clang -g % -o out
4. Put breakpoint on 2nd line (SPC + b)
5. Create new window with :new
6. Switch back to previous window (CTRL-w + CTRL-p)
7. Run debugger (F5) and specify path to the out file
8. Step into few times (F9)

Assembly will appear in both windows