nvim-dap not call disconnect leads lldb-vscode crash after debug session stop

[comicfans]

Debug adapter definition and debug configuration

installed debugger adapter: lldb-vscode from

1. LLVM-17.0.6-win64
2. msys2 clang64 lldb package 17.0.6-1 (both same problem)

nvim-dap config

local dap = require('dap')

dap.adapters.lldb = {
    type = 'executable',
    command = vim.loop.os_uname().sysname:find "Windows" and 'D:/keep/llvm/bin/lldb-vscode.exe' or '/usr/bin/lldb-vscode',
    name = 'lldb-vscode'
}

dap.adapters.codelldb = {
  type = 'server',
  port = "${port}",
  executable = {
    -- CHANGE THIS to your path!
    command = codelldb_path,
    args = {"--port", "${port}"},

    -- On windows you may have to uncomment this:
    -- detached = false,
  }
}

dap.configurations.cpp = {
    {
            name = "lldb-vscode",
            type = "lldb",
            request = "launch",
            program = function()
                return vim.fn.input('Path to executable: ', vim.api.nvim_buf_get_name(0)..'.exe' , 'file')
            end,
            cwd = '${workspaceFolder}',
            stopOnEntry = true,
    },
    {
    name = "codelldb",
    type = "codelldb",
    request = "launch",
    program = function()
        return vim.fn.input('Path to executable: ', vim.api.nvim_buf_get_name(0)..'.exe' , 'file')
    end,
    cwd = '${workspaceFolder}',
    stopOnEntry = false,
  },

}

Debug adapter version

No response

Steps to Reproduce

1. build a simple cpp int main(){} with clang++
2. debug it use lldb-vscode profile
3. let it continue run until exit

Expected Result

dap-repl shouldn't show crash info

Actual Result

4. dap-repl window shows

   PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
   Exception Code: 0xC000001D
   #0 0x00007ff73a766e76 (D:\keep\llvm\bin\lldb-vscode.exe+0x56e76)
   #1 0x00007ffd97e01881 (C:\Windows\System32\ucrtbase.dll+0x71881)
   #2 0x00007ffd97e02851 (C:\Windows\System32\ucrtbase.dll+0x72851)
   #3 0x00007ff73a754e9a (D:\keep\llvm\bin\lldb-vscode.exe+0x44e9a)
   #4 0x00007ff73a742916 (D:\keep\llvm\bin\lldb-vscode.exe+0x32916)
   #5 0x00007ffd97da42d6 (C:\Windows\System32\ucrtbase.dll+0x142d6)
   #6 0x00007ffd97da41fb (C:\Windows\System32\ucrtbase.dll+0x141fb)
   #7 0x00007ffd97da41b4 (C:\Windows\System32\ucrtbase.dll+0x141b4)
   #8 0x00007ffd97db0522 (C:\Windows\System32\ucrtbase.dll+0x20522)
   #9 0x00007ffd97db04ab (C:\Windows\System32\ucrtbase.dll+0x204ab)
   #10 0x00007ffd97db044e (C:\Windows\System32\ucrtbase.dll+0x2044e)
   #11 0x00007ff73a752887 (D:\keep\llvm\bin\lldb-vscode.exe+0x42887)
   #12 0x00007ffd99e77344 (C:\Windows\System32\KERNEL32.DLL+0x17344)
   #13 0x00007ffd9a0626b1 (C:\Windows\SYSTEM32\ntdll.dll+0x526b1)

   dap.log

this problem also discussed here seems that nvim-dap not send disconnect request, leads lldb-vscode crash at exit

[mfussenegger]

seems that nvim-dap not send disconnect request, leads lldb-vscode crash at exit

I don't understand how nvim-dap is supposed to send a disconnect request if the program runs to completion by itself.

See https://microsoft.github.io/debug-adapter-protocol/overview - the section "Debug session end":

There is no indication that the client should send a disconnect when the debugger exits. And before it exits the client wouldn't know when it should sent it. A terminate/disconnect is only sent if you as user call it, to terminate the program before it has run to completion.

[comicfans]

so if I understand correctly, when program exit by itself, nvim-dap is not responsible for sending disconnect request, and lldb-vscode should exit normally by the dap specification?

[mfussenegger]

so if I understand correctly, when program exit by itself, nvim-dap is not responsible for sending disconnect request, and lldb-vscode should exit normally by the dap specification?

Yes. That's my interpretation of the spec and I'm also not aware of any other debug adapter having a problem with the current behavior.

[mfussenegger]

Closing this for now but if there's any new insights that would point towards this being a client issue please let me know.