Vscode-cmake-tools: Error when running lldb debugger from bottom toolbar

Created on 2 Aug 2018 · 22Comments · Source: microsoft/vscode-cmake-tools

Brief Issue Summary

When clicking on 'Debug' from the bottom toolbar the lldb debugger fails to start with an error in the debug console. Pressing F5 however, will launch the debugger correctly.

Expected Behavior

This used to work in previous versions.

CMake Tools Log

DEBUG CONSOLE log:

Starting: "/usr/bin/lldb" --interpreter=mi
lldb: unrecognized option `--interpreter=mi'
error: unknown or ambiguous option
Usage:
....

Platform and Versions

Operating System: macOS 10.12.6
CMake Version: 3.20.2
VSCode Version: 1.25.1
CMake Tools Extension Version: 1.1.1
Compiler/Toolchain: clang 9.0.0

Other Notes/Information

launch.json:
"version": "0.2.0",
"configurations": [
{
"name": "(lldb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/service/app",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}/service",
"environment": [],
"externalConsole": false,
"MIMode": "lldb",
}
]

$ lldb --version
lldb-900.0.64
Swift-4.0

debulaunch feedback wanted! tweak

Source

rnorton1

Most helpful comment

@vector-of-bool hi, 1.1.3 does not solve it automatically for me. I am using this workaround at the moment:

    "cmake.debugConfig": {
        "stopAtEntry": false,
        "MIMode": "lldb",
        "miDebuggerPath": "/Users/felikz/.vscode/extensions/ms-vscode.cpptools-0.20.1/debugAdapters/lldb/bin/lldb-mi",
        "logging": {
                "trace": true,
                "engineLogging": true,
                "traceResponse": true
        }
    },

FelikZ on 11 Dec 2018

👍6 🚀3 ❤2

All 22 comments

The debug button in the bottom toolbar generates its own launch.json config on-the fly to run the debugger. It won't use lldb or any settings you've provided in your launch.json. You probably want to use the launch.json integration to use F5 to debug your app with the CMake smarts. Read about that here.

vector-of-bool on 2 Aug 2018

👍2

Wouldnt you ultimately want to integrate it with the existing launch system configuration(s) rather than generating your own on the fly? Or as a quick fix, maybe you could take a stab at the debugger from the compiler being used?

The debugger on the tool bar is a nice feature. I think it would be worth expanding on to cater for all configurations.

rnorton1 on 6 Aug 2018

👍4

Sorry for the delay, have been busy with another project.

The debug button is honestly causing me quite a bit of grief. Choosing the correct debugger is a bit more complicated than just inspecting the compiler. It may be possible to have several on-the-fly-config templates for the popular debugging engines.

It boils down to the debug button being _hard to use correctly_, but _easy to use incorrectly_.

vector-of-bool on 14 Aug 2018

No problem.

I guess a choice of on-the-fly would be ok (particularly if lldb is supported :) ). Maybe there is a technical reason i am not aware of, but wouldnt it be simpler just to use the default launch configuration that is built into VSC rather than create a bespoke on-the-fly?

rnorton1 on 14 Aug 2018

The intial goal was to not require a launch.json, which was problematic to write when the program path could not be determined beforehand. Will command substitution (the new recommended way) it isn't as much of a problem.

vector-of-bool on 15 Aug 2018

Sounds like a plan. Thanks for your time and I appreciate your hard work on this extension.

rnorton1 on 15 Aug 2018

Just got bitten by the same issue, indeed. (And found the new advice to use command substitution, thanks)

zakalawe on 18 Aug 2018

I was using debug button for last year and it was working flawlessly.

Recently I've upgraded to v1.1.1 and got:

Unable to start debugging. Unable to establish a connection to LLDB. The following message was written to stderr:

lldb: unrecognized option `--interpreter=mi'
error: unknown or ambiguous option

See Output Window for details.

Output window:

Starting: "/usr/bin/lldb" --interpreter=mi
Usage:
  lldb -h
  lldb -v [[--] <PROGRAM-ARG-1> [<PROGRAM_ARG-2> ...]]
  lldb -a <arch> -f <filename> [-c <filename>] [-s <filename>] [-o <none>] [-S <filename>] [-O <none>] [-k <none>] [-K <filename>] [-Q] [-b] [-e] [-x] [-X] [-l <script-language>] [-d] [[--] <PROGRAM-ARG-1> [<PROGRAM_ARG-2> ...]]
  lldb -n <process-name> -w [-s <filename>] [-o <none>] [-S <filename>] [-O <none>] [-k <none>] [-K <filename>] [-Q] [-b] [-e] [-x] [-X] [-l <script-language>] [-d]
  lldb -p <pid> [-s <filename>] [-o <none>] [-S <filename>] [-O <none>] [-k <none>] [-K <filename>] [-Q] [-b] [-e] [-x] [-X] [-l <script-language>] [-d]
  lldb -P
  lldb -r [<none>] -R <none>
       -h
       --help
            Prints out the usage information for the LLDB debugger.
       -v
       --version
            Prints out the current version number of the LLDB debugger.
       -a <arch>
       --arch <arch>
            Tells the debugger to use the specified architecture when starting
            and running the program.  <architecture> must be one of the
            architectures for which the program was compiled.
       -f <filename>
       --file <filename>
            Tells the debugger to use the file <filename> as the program to be
            debugged.
       -c <filename>
       --core <filename>
            Tells the debugger to use the fullpath to <path> as the core file.
       -p <pid>
       --attach-pid <pid>
            Tells the debugger to attach to a process with the given pid.
       -n <process-name>
       --attach-name <process-name>
            Tells the debugger to attach to a process with the given name.
       -w
       --wait-for
            Tells the debugger to wait for a process with the given pid or name
            to launch before attaching.
       -s <filename>
       --source <filename>
            Tells the debugger to read in and execute the lldb commands in the
            given file, after any file provided on the command line has been
            loaded.
       -o
       --one-line
            Tells the debugger to execute this one-line lldb command after any
            file provided on the command line has been loaded.
       -S <filename>
       --source-before-file <filename>
            Tells the debugger to read in and execute the lldb commands in the
            given file, before any file provided on the command line has been
            loaded.
       -O
       --one-line-before-file
            Tells the debugger to execute this one-line lldb command before any
            file provided on the command line has been loaded.
       -k
       --one-line-on-crash
            When in batch mode, tells the debugger to execute this one-line
            lldb command if the target crashes.
       -K <filename>
       --source-on-crash <filename>
            When in batch mode, tells the debugger to source this file of lldb
            commands if the target crashes.
       -Q
       --source-quietly
            Tells the debugger to execute this one-line lldb command before any
            file provided on the command line has been loaded.
       -b
       --batch
            Tells the debugger to run the commands from -s, -S, -o & -O, and
            then quit.  However if any run command stopped due to a signal or
            crash, the debugger will return to the interactive prompt at the
            place of the crash.
       -e
       --editor
            Tells the debugger to open source files using the host's "external
            editor" mechanism.
       -x
       --no-lldbinit
            Do not automatically parse any '.lldbinit' files.
       -X
       --no-use-colors
            Do not use colors.
       -P
       --python-path
            Prints out the path to the lldb.py file for this version of lldb.
       -l <script-language>
       --script-language <script-language>
            Tells the debugger to use the specified scripting language for
            user-defined scripts, rather than the default.  Valid scripting
            languages that can be specified include Python, Perl, Ruby and Tcl.
            Currently only the Python extensions have been implemented.
       -d
       --debug
            Tells the debugger to print out extra information for debugging
            itself.
       -r
       --repl
            Runs lldb in REPL mode with a stub process.
       -R
       --repl-language
            Chooses the language for the REPL.
  Notes:
       Multiple "-s" and "-o" options can be provided.  They will be processed
       from left to right in order, with the source files and commands
       interleaved.  The same is true of the "-S" and "-O" options.  The before
       file and after file sets can intermixed freely, the command parser will
       sort them out.  The order of the file specifiers ("-c", "-f", etc.) is
       not significant in this regard.
       If you don't provide -f then the first argument will be the file to be
       debugged which means that 'lldb -- <filename> [<ARG1> [<ARG2>]]' also
       works.  But remember to end the options with "--" if any of your
       arguments have a "-" in them.
lldb: unrecognized option `--interpreter=mi'
error: unknown or ambiguous option
"/usr/bin/lldb" exited with code 0 (0x0).

And so I've found this thread. I've tried to configure gdb as it suggested here on OSX and got this:

WARNING: Debugger executable '/usr/local/bin/gdb' is not signed. As a result, debugging may not work properly.

I will update this comment if I will find a solution.

FelikZ on 21 Aug 2018

You can still use the LLDB debugger. You just cant use it (at the moment) through the cmake-tools menu bar at the bottom. Set up a launch configuration (Debug -> Add Configuration) like the one in the OP. Then hit 'F5' key when you want to debug.

vector-of-bool seemed to be saying he will fix it from the cmake-tools menu bar by using these launch configuration profiles in the future.

rnorton1 on 21 Aug 2018

👍1

I'm kinda confused, so how should I debug? From what @rnorton1 replies, is it accurate to say that I can just ignore the button on the bottom status bar, and use the old school launch.json instead?

jackxujh on 29 Nov 2018

Not exactly "old school" launch.json, but you should read these docs. You can set a lot more debugging options via launch.json than are otherwise available, while still getting the proper CMake integration.

vector-of-bool on 2 Dec 2018

@FelikZ Sorry to get back to you so late on this, but I had an issue from the cpptools team that I am passing the wrong lldb filepath when starting the debugger. 1.1.3 switches to passing lldb-mi, which is the correct debugging executable. If this is still an issue you've been experiencing, did the 1.1.3 release help at all?

vector-of-bool on 2 Dec 2018

No its still the same issue in 1.1.3:

Unable to start debugging. Unable to establish a connection to LLDB. The following message was written to stderr:

lldb: unrecognized option `--interpreter=mi'
error: unknown or ambiguous option

Still need to use the launch.json instead of the Debug button.

rnorton1 on 3 Dec 2018

👍1

@rnorton1 do you have an lldb-mi executable on your PATH?

vector-of-bool on 10 Dec 2018

Its in two places:

/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-mi
/Users/rnorton/.vscode/extensions/ms-vscode.cpptools-0.20.1/debugAdapters/lldb/bin/lldb-mi

Which looks to be the problem as from the Output Dialog:

[proc] Executing command: /usr/bin/lldb-mi --version
[proc] Executing command: /usr/bin/gdb --version
[proc] Executing command: /usr/bin/lldb --version
[proc] Executing command: /usr/bin/lldb --version

It appears to be looking for it in /usr/bin exclusively.
However because of SIP (Apple's System Integrity Protection), i cant put a sym link in there. Adding it so its in the path ( in /usr/local/bin for example), does not work (even though it's recognisable by command line and i restarted VSC).

Some questions:

Is my system 'mis-configured' because of no link in /usr/bin?
What is the lldb-mi that you provide in the debugAdapters sub dir?
Clearly there is a process happening whereby the application is trying to find the binary using --version. Is there a way to configure a different path to check (like /usr/local/bin)?

Thanks again for your help.

rnorton1 on 10 Dec 2018

@vector-of-bool hi, 1.1.3 does not solve it automatically for me. I am using this workaround at the moment:

    "cmake.debugConfig": {
        "stopAtEntry": false,
        "MIMode": "lldb",
        "miDebuggerPath": "/Users/felikz/.vscode/extensions/ms-vscode.cpptools-0.20.1/debugAdapters/lldb/bin/lldb-mi",
        "logging": {
                "trace": true,
                "engineLogging": true,
                "traceResponse": true
        }
    },

FelikZ on 11 Dec 2018

👍6 🚀3 ❤2

I fixed my issue by changing gdb to lldb in my launch.json file:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(lldb) Launch", // Here!!
            "type": "cppdbg",
            "request": "launch",
            // Resolved by CMake Tools:
            "program": "${command:cmake.launchTargetPath}",
            "args": [],
            "stopAtEntry": true,
            "cwd": "${workspaceFolder}",
            "environment": [
                {
                    "name": "PATH",
                    "value": "$PATH:$HOME/some_path"
                },
                {
                    "name": "OTHER_VALUE",
                    "value": "Something something"
                }
            ],
            "externalConsole": true,
            "MIMode": "lldb", // also here!!
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for lldb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        }
    ]
}

seanngpack on 29 Sep 2019

Yes that is my workaround too:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(lldb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${command:cmake.launchTargetPath}",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${config:cmake.buildDirectory}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "lldb",
            "setupCommands": [{ "description": "Enable pretty-printing for lldb", "text": "-enable-pretty-printing", "ignoreFailures": true } ]
        }
    ]
}

However the original issues still exists - there is no way to configure the shortcut 'Debug button' on the toolbar to use anything other than the auto-generated script, and the auto-generated script does not work for lldb.

To use lldb, you must write your own launch.json (as above) and launch it via VSCode, not the toolbar. I am hoping @vector-of-bool will provide a clean solution when he has time.

rnorton1 on 30 Sep 2019

@rnorton1, @seanngpack, you can use the cmake.debugConfig setting to override CMake Tools' defaults without writing a launch.json as a workaround as in @FelikZ's comment

bobbrow on 30 Sep 2019

Thanks very much @bobbrow ! That worked for me too - I will close this thread.

rnorton1 on 30 Sep 2019

CMake seems to igonre cmake.debugConfig. At least it does not use it in my case. Using VSC-s debugger seems to be ok (launches /usr/bin/lldb), but cmake insists on looking for lldb in /opt/local/bin even though I don't have it installed there. It seems to make no attempt at looking for the one included with cpptools even though I've explicitly specified it in the debugConfig parameter.

"cmake.debugConfig": {
  "stopAtEntry": false,
  "MIMode": "lldb",
  "miDebuggerPath": "/Users/xxxx/.vscode/extensions/ms-vscode.cpptools-0.26.3/debugAdapters/lldb/bin/lldb-mi",
  "logging": {
    "trace": true,
    "engineLogging": true,
    "traceResponse": true
  }
},

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(lldb) Launch",
      "type": "cppdbg",
      "request": "launch",
      // Resolved by CMake Tools:
      "program": "${command:cmake.launchTargetPath}",
      "args": [],
      "stopAtEntry": true,
      "cwd": "${workspaceFolder}",
      "environment": [
        {
          // Just an example
          "name": "PATH",
          "value": "$PATH:$HOME"
        }
      ],
      "externalConsole": false,
      "MIMode": "lldb",
      "setupCommands": []
    }
  ]
}

johankytt on 9 Feb 2020

@johankytt, I am not reproducing this with CMake Tools 1.3.0. I wonder what is different about your scenario. I am having cmake.debugConfig settings (MIMode and paths, gdb and lldb) getting read from workspace settings just fine.
Also, this issue was reported https://github.com/microsoft/vscode-cmake-tools/issues/1060 and I am not reproducing that either.