Getting "Source not available, cannot jump to frame" when using C with lldb-dap on Mac M1

[benjitrosch]

Debug adapter definition and debug configuration

dap.adapters.lldb = {
    type = 'executable',
    command = '/opt/homebrew/Cellar/llvm/18.1.4/bin/lldb-dap',
    name = 'lldb',
}

dap.configurations.cpp = {
    {
        name = 'game',
        type = 'lldb',
        request = 'launch',
        program = function()
            return vim.fn.getcwd() .. '/build/game'
        end,
        cwd = '${workspaceFolder}',
        stopOnEntry = true, -- When this is set to false, I cannot even pause the application because it cannot find the thread
        args = {},
    },
}

dap.configurations.c = dap.configurations.cpp

Debug adapter version

0.7.0

Steps to Reproduce

1. Build with CMake (with debug symbols using -g): cmake -B build -DCMAKE_BUILD_TYPE=Debug followed by cmake --build build
2. Set a breakpoint: :lua require'dap'.toggle_breakpoint()
3. Launch the executable: :lua require'dap'.continue()
4. It is paused as expected (due to stopOnEntry) and message "Source not available, cannot jump to frame" appears
5. After playing the breakpoint is not stopped at

Expected Result

The executable should pause at breakpoint.

I've verified that debug symbols are being created, and additionally this works when I've manually tested outside of neovim using my terminal and the regular lldb command. However, using nvim-dap and lldb-dap does not work.

Actual Result

dap.log

[mfussenegger]

The stacktraces reported by the debug adapter have no sources:

    stackFrames = { {
        column = 0,
        id = 524288,
        instructionPointerReference = "0x100E7E4C8",
        line = 0,
        name = "__sanitizer::SizeClassAllocator32<__asan::AP32<__sanitizer::LocalAddressSpaceView>>::PopulateFreeList(__sanitizer::AllocatorStats*, __sanitizer::SizeClassAllocator32LocalCache<__sanitizer::SizeClassAllocator32<__asan::AP32<__sanitizer::LocalAddressSpaceView>>>*, __sanitizer::SizeClassAllocator32<__asan::AP32<__sanitizer::LocalAddressSpaceView>>::SizeClassInfo*, unsigned long)",
        presentationHint = "subtle"
      }, {

Not much the client can do about that. Given that you didn't' post any sources I also can't reproduce this.

[benjitrosch]

@mfussenegger sorry about that, my mistake. Here's small repo for you to use: https://github.com/benjitrosch/c-dap-example/tree/main

[mfussenegger]

The example works fine for me - tested with all 3: lldb-vscode (version 17.0.6) , codelldb and gdb.

stackFrames from lldb-vscode look like this for me:

  body = {
    stackFrames = { {
        column = 3,
        id = 524288,
        line = 13,
        name = "main",
        source = {
          name = "main.c",
          path = "/path/to/benjitrosch/c-dap-example/main.c"
        }
      }, {
        column = 0,
        id = 524289,
        line = 27,
        name = "___lldb_unnamed_symbol3264",
        source = {
          name = "___lldb_unnamed_symbol3264",
          sourceReference = 1
        }
      }, {

[benjitrosch]

Thanks for trying it out. Really weird that it's not working for me.

I'm using lldb-dap which gets installed from brew install llvm which is at version 18.1.4. I tried downgrading with brew install llvm@17 but then neither lldb-dap nor lldb-vscode were anywhere to be found.

Not sure what other info I could provide, please LMK.

[mfussenegger]

I think you'll have to report that upstream. I don't really see what else the client could do here and I don't have a Mac M1 to test with myself.

[Dudenwatschn]

I just wanted to chime in, since I managed to reproduce this issue on a raspberry-pi (armv7a) using llvm 18.1.8. Downgrading to 17.0.6 seems to resolve the problem - this might be a general issue with lldb-dap that also occurs on other platforms.

I'll try to verify this. If this is an issue with version 18 of lldb, we might at least add a note to the DAP-configuration section informing people about possible issues.

[benjitrosch]

Thanks for verifying that @Dudenwatschn. Not long after this, I had the exact same issue on a Windows machine running WSL—so definitely not exclusive the Mac M1's. I'm inclined to believe the issue started when lldb-vscode switched to lldb-dap.

[Dudenwatschn]

@benjitrosch Hmm. weird. I just got it to run on WSL(Arch) using the current version of lldb from pacman (18.1.8-1).

I don't know how you installed it on WSL. On Raspberry I got the latest image off lldbs github-releases. Debugging with the regular lldb cmdline-interface of that version worked just as expected - that's why I first assumed that the problem was in the configuration I passed to lldb-dap. But this doesn't seem to be the case. I tried to do a quick check for any missing dependencies of lldb-dap but couldn't find anything suspicious. So either I missed something - or this issue is just related to the current phase of the moon.

Note: This is the config which flawlessly worked for me with lldb 18.1.8 (in combination with a small Hello-World test program)

dap.adapters.lldb = {
	type = "executable",
	command = "/usr/sbin/lldb-dap",
	name = "lldb-dap",
}

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