Doesn't work in MacOS Sonoma.

[mumin16]

Initial debug configuration: { type: 'lldb', request: 'launch', name: 'Debug', program: '${workspaceFolder}/build/Musavir', args: [], cwd: '${workspaceFolder}/../bin', configurationTarget: 6 } Resolved debug configuration: { type: 'lldb', request: 'launch', name: 'Debug', program: '${workspaceFolder}/build/Musavir', args: [], cwd: '${workspaceFolder}/../bin', configurationTarget: 6, relativePathBase: '/Users/x64/VSCodeProjects/Musavir', _adapterSettings: { displayFormat: 'auto', showDisassembly: 'auto', dereferencePointers: true, suppressMissingSourceFiles: true, evaluationTimeout: 5, consoleMode: 'commands', sourceLanguages: null, terminalPromptClear: null, evaluateForHovers: true, commandCompletions: true, reproducer: false } } Debug adapter exit code=0 (0x0), signal=null.

[tmam444]

I hope the following link will be helpful to you.

https://github.com/vadimcn/codelldb/discussions/456#discussioncomment-874122

[mumin16]

thanks mate! it is working...

[stijnfrishert]

Have the same problem. Recently installed macOS Sonoma on my Intel MBP and every debug session returns -1.

https://github.com/vadimcn/codelldb/discussions/456#discussioncomment-874122 solves it for me too. Workable for now, though I hope a future release will solve this properly. :)

If I can help with logs or anything, let me know.

[nsh-ableton]

Hi — after struggling with this for a day, I came here to file an issue and stumbled across this. (Didn't appear in my searches before). Just upgraded an Intel iMac Pro to Sonoma and could not get CodeLLDB to work. Deleting debugserver did the trick. 😅 Seems like a good thing to wrap into an update soon. 😉 Thanks for the awesome extension!

[vadimcn]

I don't own a Mac currently, so I can't investigate what's going on there, sorry.
I can just stop bundling a debugserver for x64 macos, of course, but that means everyone will need to install xcode command line tools in order to use codelldb.

[nsh-ableton]

I'd suggest that's probably a good idea. I think there are other tools around that require people to install xcode command line tools, and the added hassle of that is probably worth avoiding this confusing situation. Or maybe just a prominent note in the installation instructions could help?

[stijnfrishert]

Don't think that's such a weird requirement, tbh.

Where are you getting the debugserver? Maybe it's just a question of bundling the latest?

[vadimcn]

Don't think that's such a weird requirement, tbh.

One of my goals was to make CodeLLDB self-sufficient, so that you wouldn't need to install anything besides the VSCode extension. I must admit, this turned out to be harder to achieve than I had expected :unamused:

Where are you getting the debugserver? Maybe it's just a question of bundling the latest?

The debugserver comes from xcode 10 command line tools, IIRC. The reason for using an old version being that newer versions didn't work on older MacOS'es, however this one seemed to be universally compatible.

[stijnfrishert]

One of my goals was to make CodeLLDB self-sufficient, so that you wouldn't need to install anything besides the VSCode extension. I must admit, this turned out to be harder to achieve than I had expected 😒

Yeah, that would definitely be the most convenient. And CodeLLDB has been super convenient, so thank you for your hard work. 👍

The debugserver comes from xcode 10 command line tools, IIRC. The reason for using an old version being that newer versions didn't work on older MacOS'es, however this one seemed to be universally compatible.

I guess it worked up til now. Apparently there is no version of the debugserver that works on all version from 10 up to Sonoma :/

Even it hadn't broken now, I guess we can never have the guarantee 10's debugserver will continue working on all future versions of macOS. The only way out I see is: either you bundle the new debugserver too and somehow pick the right one one at install/runtime, or people have to install it themselves. 🤔

Imho the second option is less convenient, but it does make every version of CodeLLDB future compatible, because future users can just upgrade the debugserver themselves.

[puremourning]

Suggestion: use the debug server from Xcode/CLT if it is there, else fall back to the bundled one?

[stijnfrishert]

Is there any way forward with this issue? Just ran into on the C++ codebase at my work and I'm certain a lot more people will now that Sonoma is getting more traction.

[vadimcn]

Here's a new build that includes a more recent debugserver: v1.10.1-dev.2312052337 Can people please try it out?

I can't test it myself, as I don't have the hardware. And so far I was not able to install Sonoma in a VM (does anybody have a link to working instructions, or better yet, a ready-made QEMU image?).

[jjaine]

I'm on Ventura but using Xcode 15.0.1 and have the same problem, and the v1.10.1-dev.2312052337 did not resolve the problem for me.

[stijnfrishert]

Nope, didn't resolve it, @vadimcn :/

Don't know how to help you with Sonoma, but I'm happy to offer testing builds on my intel MBP if you've got more.

[puremourning]

@vadimcn I'm more than happy to test out CodeLLDB on macOS (regularly), and contribute solutions.

Having some trouble building locally just now. If you're not sure about the problem in that discussion, I can spend some time to work it out/fix it.

[mqtthiqs]

Hello there, thanks @vadimcn for your hard work. Got bitten by this too (Intel/Sonoma); came here for help and removing the bundled debugserver solved it for me too. I also think using the system's lldb is a better idea, falling back to downloading your build if necessary. Or at least offering a setting to let us choose its path.

Incidentally I just cannot imagine a use case where one would like to debug a process but would not have macOS' Command line tools installed TBH.

[nine9ths]

I'm on an M1 Sonoma 14.4.1 (23E224), none of the suggested workarounds fix this problem for me. I've updated to the latest version of Sonoma, removed and reinstalled all my extensions, and removed the bundled debugserver, still getting the same error.

Just running lldb from the commandline seems to work fine. lldb --version gives this:

lldb-1500.0.404.7
Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)

I can sort of get it to work with the following steps.

1. Click the "Debug" button in CodeLens of some test, I get the "MIDebuggerPath" error.
2. Click "Open 'launch.json'"
3. Select "LLDB"
4. Get a message "Cargo.toml has been detected in this workspace. Would you like to generate launch configurations for its targets?" Select "Yes". A launch.json has now been created.
5. Set some breakpoint and Press F5—the debugger will start successfully.

However, if I try with the CodeLens debug button, even with the launch.json generated above I still get the "MIDebuggerPath" error.

This method produces these results whether or not I have removed debugserver from the vadimcn.vscode-lldb-1.10.0/lldb/bin directory.

Note prior to Sonoma, I did not need to create any launch.json for debugging with CodeLens to work.

Edited to add the generated launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug unit tests in library 'read-timeout'",
            "cargo": {
                "args": [
                    "test",
                    "--no-run",
                    "--lib",
                    "--package=read-timeout"
                ],
                "filter": {
                    "name": "read-timeout",
                    "kind": "lib"
                }
            },
            "args": [],
            "cwd": "${workspaceFolder}"
        }
    ]
}

[jayz22]

+1 to what @nine9ths posted above. I've encountered the same issue and has tried the exact same steps as described above but could not solve it. It was working perfectly ~2 months ago. I'm on M1 Monterey Version 12.7.2. Any help would be greatly appreciated!

[jonataslaw]

Same problem here, I just update my mac

[nine9ths]

This started working for me without any direct intervention on my part. I believe a VS Code or Rust Analyzer update resolved the issue.

Unfortunately, I did not note the VS Code version in my previous report. I'm currently on VS Code Version: 1.89.0 Commit: b58957e67ee1e712cebf466b995adf4c5307b2bd and rust-analyzer version: 0.3.1950-standalone (c4618fe14 2024-05-05)

Still on the same version of MacOS as noted above.