Troubleshooting

Debugger does not start

Usually, you'll be able to find more details about CodeLLDB errors in its log, which can be found in the VSCode's OUTPUT panel. Be sure to switch view to "LLDB" channel. If this proves unenlightening, try enabling verbose logging by adding "lldb.verboseLogging": true into user/workspace settings.

Debugger does not start, /lib64/libc.so.6: version 'GLIBC_2.18' not found message can be seen in the log

This may happen if you are running a Linux distro, which has an glibc older than 2.18. Currently the only workaround seems to be upgrading the glibc library. This guide might be helpful in this task, but please note that you'll need to modify steps to install glibc 2.18, not 2.17.

Alternatively, you may install LLDB using you distro's package manager, then tell CodeLLDB to use it as a backend as described here. Of course, this LLDB will likely be old and won't have any Rust support.

Error message: Could not initialize Python interpreter - only native expressions will be available.

This is a non-fatal error which indicates that CodeLLDB could not initialize the Python expression evaluator and that both "simple" and "python" expressions will not be available in the current debug session. This may be normal if you are using CodeLLDB in an environment without a Python interpreter, such as a minimal Docker container. In order to suppress the error, set the expressions parameter of the launch configuration to native.

Debugger does not stop on breakpoints / breakpoints are grayed-out.

This usually means that the debugger cannot locate debugging symbols for your program. Here's a few things to check:

• Check whether you are compiling with debug symbols. Most C++ compilers, as well as the Rust compiler, use -g flag to enable emission of debug info. When using a build system, such as CMake or Cargo, make sure you've selected a debug build type. You can check whether your binary has debug symbols by following these instructions.

When debugging Swift binaries, local variables are garbled or not shown at all.

The default LLDB backend bundled with CodeLLDB supports C, C++ and Rust (as well as other languages whose debug info is compatible with C++), but now Swift. It appears that Swift has diverged far enough from C++ that LLDB cannot interpret its debug info without a special Swift plugin anymore.
It is, however, still possible to debug Swift programs using CodeLLDB by directing it to use an alternate backend, namely, the one provided with the Swift toolchain:

• Open VSCode commands palette and search for "LLDB: Use Alternate Backend..." command.
• At the prompt, enter executable name of the LLDB instance you want to use. On MacOS, you should use the default system instance (i.e. just lldb). On Linux, look for lldb in <swift install root>/usr/bin directory.
• If all goes well, CodeLLDB should report that it has located the library it needs and ask for your confirmation, after which it will add lldb.library configuration setting in the current workspace.

Electron applications fail to launch under the debugger.

...with an error similar to this:

const rc = app.rc = require('../rc')      
TypeError: Cannot set property 'rc' of undefined

Electron applications typically consist of several cooperating processes, some of which have specific roles, as configured by environment variables set the main process. Since VSCode is an Electron application itself, its children, including the debugger and the debuggee will inherit these variables as well, which may cause them to function incorrectly. The solution is to reset all ELECTRON_... variables in the launch configuration:

"env": { 
    "ELECTRON_RUN_AS_NODE": "",
    "ELECTRON_NO_ATTACH_CONSOLE": "",
}

Debugging fails to start with this error message: process launch failed: 'A' packet returned an error: 8.

This is the catch-all message for LLDB's failure to create a debuggee process. Some common reasons include:

• Current working directory ("cwd") having been set to non-existent or inaccessible path.
• Debugging inside an unprivileged Docker container with disabled ASLR. While disabling ASLR is generally desirable during debugging (because it may cause non-determinism of program execution), doing so may be disallowed by the default container security profile. Possible solutions:
  • Relax container security profile by starting it with --security-opt seccomp=unconfined option.
  • Turn off ASLR disabling by adding "initCommands": ["set set target.disable-aslr false"] to your launch configuration.