Unable to debug my test

[bobbrow]

I am facing a similar issue with one of my cmake projects. I am trying to run this on a remote machine. The host machine is OSX 11.4 (Big Sur). The remote is a Ubuntu 20.04.3. The project configures and builds okay. But I am not able to debug any of my unit tests. This is the error I get when I right-click on the test and press 'Debug'

[extension] [1484] cmake.debugTarget started [main] Failed to prepare executable target with name 'core-01_hello_test.cpp' [extension] [1484] cmake.debugTarget finished (returned null)

Does not give me any other information.

This is what my cmake command looks like:

"cmake .. -DCMAKE_BUILD_TYPE=Debug -GNinja"

I have tried Debug, 'Debug', and also 'DEBUG'. Doesn't seem to make a difference.

Originally posted by @CatsNipYummy in #1692 (comment)

[bobbrow]

@CatsNipYummy, can you set the cmake.loggingLevel setting to "Debug" and retry the scenario? Then paste the log output here. There's more information we can get from the extension between cmake.debugTarget started and cmake.debugTarget finished. I'm most interested in what the extension says on this line:

[main] Starting debugger with following configuration. {...}

[CatsNipYummy]

@bobbrow I believe I've set the cmake.loggingLevel to "Debug" for User, Remote, and Workspace. Doesn't seem to be giving me any more logs. Am I missing something here?

https://imgur.com/a/wg0GFVa

[extension] [5039] cmake.debugTarget started [main] Failed to prepare executable target with name 'core-01_hello_test.cpp' [extension] [5039] cmake.debugTarget finished (returned null)

[bobbrow]

If it's set in all 3, the value in the Workspace setting wins.
Could you try reloading the window and see if that fixes the logging? There's a "Reload Window" command you can use in VS Code so that you don't have to close and reopen the whole window frame.

[CatsNipYummy]

I tried the "reload window" command and also manually restarting VS Code. Removed my build folder and ran cmake again. Dont seem to be getting any extra logs. Are these write to a log file I can look at?

[bobbrow]

It should just be writing to the OUTPUT window. This is what mine looks like with the extra messages between debug start and debug finish.

[bobbrow]

Ok, let me look at the code, it could be because of the failure on the "start" line that it's exiting early.

[bobbrow]

The code that is failing is looking for an executable target. Can you share a screenshot of the CMAKE: PROJECT OUTLINE panel, or is there a repo we can clone? The name of the target it's looking for has a .cpp extension which seems a little suspicious.

[CatsNipYummy]

The logs I shared with you are from the 'output' panel.

Unfortunately, can't share the codebase. This is what a part of the outline panel looks like

I've renamed some of the internal namings of the project 😄

The unit tests do have the .cpp extension to them. That part has been set up for a while. Is there a way to know if that's what's throwing the cmake tools off?

[bobbrow]

The file extension shouldn't throw cmake tools off. CMake Tools just needs the target to be an "executable" target. Did you add this target with add_executable() in your CMakeLists.txt?

When you right click on your target, do you get an option to set it as the Debug/Launch target? And if you select that option, does it put a rocket ship emoji next to the hammer emoji?

One last question. Are you using CMakePresets.json to configure your project?

[CatsNipYummy]

Yes I am using add_executable() in CMakeLists.txt

When I press "Debug/Launch Target", I don't see the rocket ship emoji. The output when I press that option looks the following:

[extension] [1081] cmake.selectLaunchTarget started
[extension] [1081] cmake.selectLaunchTarget finished (returned null)

I am not using CMakePresets.json . At least I'm not aware of it. Nothing along those lines exists inside my .vscode folder. Is there a local folder I can check just incase?

[bobbrow]

If you have a CMakePresets.json it would be in the same folder as your root CMakeLists.txt. I think we're going to need more logging since you can't share your project. I'll instrument the extension a bit and then send a link to install the special version.

[bobbrow]

Here is a build of the extension with some additional logging. Please set cmake.loggingLevel to "debug".

Instructions:

1. Download the zip from here: https://github.com/microsoft/vscode-cmake-tools/suites/3615402856/artifacts/87368818
2. Unzip the VSIX file.
3. Run the "Install from VSIX..." command in VS Code and point it at the VSIX file.
4. Reload the Window and try to debug the target.
5. Share the log with me or at least just the parts related to [FileAPI] or [ServerAPI] depending on your version of CMake (which version are you using, BTW?)

[CatsNipYummy]

Here's the log file. I've renamed some internal namings. So please take those typos (if any) with a pinch of salt. We're using CMake 3.21.2

VS_Code.log

[bobbrow]

Thanks. The target looks correct (it appears you removed the .cpp too, right?). I might need to add some more logging since it got past the point I thought it would fail.

One other thing I noticed in there was your usage of snaps. We don't support that right now, but there is a workaround here: #838 (comment). If you can apply that workaround and let me know if it fixes anything, that would be appreciated.

[bobbrow]

I built a new VSIX: https://github.com/microsoft/vscode-cmake-tools/suites/3617086280/artifacts/87429502

If you can install that, run your scenario and share the log again, I'll take a look.

[CatsNipYummy]

Here are the logs you requested. I've used the snap worked around as well (that's right. removed the .cpp as well)

VS_Code2.log

[CatsNipYummy]

@bobbrow do you need any other logs from my end?

[bobbrow]

Sorry I didn't get to this yesterday. The logs look strangely the same as the first one. Could you check the version number for me?

[bobbrow]

[CatsNipYummy]

Should I have the same hash as well? I don't see an official 1.8.1 release yet.

[bobbrow]

Yes, the hash number should be the same as mine. You might need to uninstall the first VSIX I gave you to get the new one to install properly. You can also "uninstall" it by deleting the matching folder under ~/.vscode/extensions.

[CatsNipYummy]

my bad. here are the logs from the right version

VS_Code3.log
As usual, I've renamed some of the logs after they were generated. So do take the naming with a pinch of salt. Thanks again

[bobbrow]

It appears that the CMAKE_BUILD_TYPE for the targets we discovered (Release) does not match the currently active build type for debugging. Unfortunately I failed to log what that was, but it should be on the status bar. Can you tell me what is selected there? Is it Release, or something else?

[bobbrow]

Another option is for me to give you a line of code for you to insert into your copy of the extension and that will add the logging.

[CatsNipYummy]

This is what I have by default

[CatsNipYummy]

Sure. I can add that line of code and see what's happening

[bobbrow]

The screenshot is sufficient. You are trying to select "Debug", but the information the extension has indicates that the "Release" configuration is being generated. Is there anything in your CMakeLists.txt that changes the CMAKE_BUILD_TYPE? I see that the generator command is correctly setting the CMAKE_BUILD_TYPE to Debug, but all of the files written here: /home/workspace/proj/build/.cmake/api/v1/reply have 'Release' in the name. You can try deleting the /home/workspace/proj/build/.cmake folder and regenerating, but it looks like the build type is changing out from under us. If you set the status bar to "CMake: [Release]: Ready", I think the debugger would start (though you'd be debugging optimized binaries)

[CatsNipYummy]

That's true. To your point, when I tried "CMake: [Release]: Ready", it did try to compile the project but then all my paths are missing. So I get 'cannot open *.h' errors.

Let me try deleting the build folder and try again. I've been doing that for all my tests each time. But let me see if something's explicitly changing the CMAKE_BUILD_TYPE to Release at some point.

[CatsNipYummy]

So I did delete the .cmake file you mentioned and I was able to get the debugger to start and I see my unit test output which is great!

The only issue is that the breakpoints are not getting activated. Even if this is in release, shouldn't the breakpoints inside int main() get called?

[bobbrow]

By default, I don't believe CMake's 'Release' config sets up the binary to have any debug information in it so that's why your breakpoints don't bind. There is a 'RelWithDebInfo' config that does that. Sorry, I should have thought of that earlier.

[CatsNipYummy]

'RelWithDebInfo' is still not doing anything for me

[extension] [7083] cmake.setVariant finished (returned 0)
[extension] [6319] cmake.debugTarget started
[cmakefileapi-driver] [FileApi] Unique targets []
[main] [prepareLaunchTargetExecutable] Looking for 'core-01_hello_proj'
[main] [prepareLaunchTargetExecutable] executableTargets []
[main] Failed to prepare executable target with name 'core-01_hello_proj'
[extension] [6319] cmake.debugTarget finished (returned null)

This does sound like a shortcut to the problem. The fact its getting switched to Release is probably why this is not working either.

[bobbrow]

Correct. This is the exact same problem as the 'Debug' config. If you can figure out where in the project the CMAKE_BUILD_TYPE is getting overwritten, I think everything should start working as expected.

[CatsNipYummy]

Dug around the project a bit and found the source of the issue. We're forcing the CMAKE_BUILD_TYPE cause of some cross-platform support like you mentioned. That's something on our end that needs to be changed. But removing that fixed this issue. Thanks a lot for your help @bobbrow . Feel free to close this issue if you like.

[bobbrow]

I'm glad you were able to resolve this. I'll close this issue, but create a new one for us to investigate whether we can throw in a warning about this type of situation.