Vscode-cmake-tools: Cannot debug on Ubuntu after update

[iboB]

Brief Issue Summary

VSCode updated the plugin to the MS one

I tried launching the debugger. It fails with

[debugger] Unable to automatically determine debugger corresponding to compiler: {}

I tried this with gcc and clang. Same result

I tried manually setting the debugger:

    "cmake.debugConfig": {
        "type": "GDB",
        "debuggerPath": "/usr/bin/gdb"
    }

Same result

CMake Tools Log

2019-11-08T07:45:56.718Z [debug] [cache] Reading CMake cache file /home/bstanimirov/prj/my/app-server/build/CMakeCache.txt
2019-11-08T07:45:56.723Z [debug] [cache] Parsing CMake cache string
2019-11-08T07:45:56.732Z [warning] [debugger] Unable to automatically determine debugger corresponding to compiler: {}
2019-11-08T07:45:56.732Z [debug] [main] Debug configuration from cache: null
2019-11-08T07:45:56.732Z [error] [main] Failed to generate debugger configuration
2019-11-08T07:45:56.733Z [debug] [extension] [8248] cmake.debugTarget finished (returned null)
2019-11-08T07:45:56.746Z [debug] [cache] Reading CMake cache file /home/bstanimirov/prj/my/app-server/build/CMakeCache.txt
2019-11-08T07:45:56.747Z [debug] [cache] Parsing CMake cache string

[iboB]

To anyone having the same issue: I downloaded a .vsix of the old version 1.1.3, uninstalled the MS extension and installed the downloaded one and everything works now

[exu1977]

I meet the same issue. @iboB where is the old version 1.1.3(.vsix)? thanks

[iboB]

I talked to the author and he sent it to me. I'm attaching it here. Rename from .zip to .vsix
cmake-tools-1.1.3.zip

[ghost]

If I use gcc-7.4.0 I have the same issues. If I install gcc-8.3.0, I can debug with that version and everything seems to work fine.
clang-6.0.0 also works for me. I did notice when I was installing other versions of gcc & clang it would sometimes stop working. At the time I was trying to get gcc to work so I don't know the exact combinations.

In any case, it would be helpful if during the detection there would be more traces so we can see what's going on.

[bobbrow]

I have a fix for this in PR. There was an update to the regular expression that mapped compilers to the debugger that caused this regression.

You can workaround this until we release an update by opening ~/.vscode/extensions/ms-vscode.cmake-tools-1.2.1/dist/main.js and replacing line 27378:

  const gcc_compiler_regex = /([cg]\+\+|g?cc)(?=\.exe$|$)/gi;

with

  const gcc_compiler_regex = /([cg]\+\+|g?cc)(?=[^\/\\]*$)/gi;

[Zingam]

With a great sadness I can confirm this too.
[build] Starting build
[proc] Executing command: /snap/cmake/current/bin/cmake --build /home/hristo/Projects/GitHub/GunBox/GunBox/GunBox/build --config Debug --target GunBox_Game -- -j 10
[build] ninja: no work to do.
[build] Build finished with exit code 0
[debugger] Unable to automatically determine debugger corresponding to compiler: {}
[main] Failed to generate debugger configuration

[bobbrow]

1.2.2 was released today. Please give that a try and let us know if you continue to have issues.

[rmclaren]

As of version 1.4.1 this is still broken on macOS Catalina.

I think this is in part because of ~/.vscode/extensions/ms-vscode.cmake-tools-1.4.1/dist/main.js line 42788 const debugger_name = platform == 'darwin' ? 'lldb' : 'gdb'. This isn't a good assumption. Just because you are using MacOS does not mean you're using lldb. It should use the debugger specified by miDebuggerPath in the launch.json or settings.json files (this configuration seems to have no effect for me).

Forcing debugger_name = 'gdb' does seem to make the debugger work sometimes (at least it finds the right debugger)... Although most of the time Visual Studio Code never attaches to the compiler. No idea why that might be (interestingly it usually works the first time when first compiling with gcc instead of clang)...

The reason I need to use GDB is because I'm trying to debug Fortran code (actually a mixed c++ and fortran code base), and unfortunately lldb does not support Fortran. If you install the Modern Fortran, and Fortran Breakpoint Support extensions and then use the GDB debugger you can debug fortran code the same way you can debug C++. I was thinking this might make a good test case if you are looking for some way to reproduce these issues.

launch.json configuration:

        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/test.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "miDebuggerPath": "/usr/local/bin/gdb",
            //"serverLaunchTimeout": 50000,
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
        }

settings.json

{
    "C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools",
    "cmake.configureOnOpen": true,
    "cmake.debugConfig": 
    {
        "stopAtEntry": false,
        "MIMode": "gdb",
        "miDebuggerPath": "/usr/local/bin/gdb",
        "logging": {
            "trace": true,
            "engineLogging": true,
            "traceResponse": true
        }
    }
}

test.f90 fortran file:

program test
    implicit none

    real :: x,y,z
    real :: result

    x = 3.0
    y = 5.0
    z = 10.0

    result = sqrt(x**2 + y**2 + z**2)
    print *, result

end program test

CMakeLists.txt

cmake_minimum_required(VERSION 3.15)

project(test
        VERSION 0.0.1
        LANGUAGES Fortran)

include(GNUInstallDirs)

set(exe test.exe)
set(srcs test.f90)
add_executable(${exe} ${srcs})

install(TARGETS ${EXE_TARGETS} RUNTIME
        DESTINATION bin
        COMPONENT utilities)

[bobbrow]

This is interesting. If you are setting the miDebuggerPath in cmake.debugConfig, the debugger_name variable shouldn't matter because a few lines down we pick the debuggerPathOverride which is supposed to be the value of cmake.debugConfig.miDebuggerPath. If you recently changed the setting and it doesn't appear to be taking effect, try reloading the window and see if the extension picks it up on the reload. There is currently an issue open where the extension doesn't reload the value of all settings after they change. #1127

[Zrealshadow]

I still face this problem in MacOS Catalina 10.15.4
And the cmake-tool verison is 1.6.0

When i try to debug,
the log is:
[build] Starting build
[proc] Executing command: /snap/cmake/current/bin/cmake --build /home/hristo/Projects/GitHub/GunBox/GunBox/GunBox/build --config Debug --target GunBox_Game -- -j 10
[build] ninja: no work to do.
[build] Build finished with exit code 0
[debugger] Unable to automatically determine debugger corresponding to compiler: /usr/local/bin/g++-8
[main] Failed to generate debugger configuration

My cmake tool setting:

    "C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools",
    "cmake.configureOnOpen":true,
    "cmake.debugConfig": {
        "stopAtEntry": false,
        "MIMode": "gdb",
        "miDebuggerPath": "/usr/local/bin/gdb",
    }

Any solution to this problem ?

[andreeis]

I opened a new issue from your last comment. I have a suspicion in the implementation.