"Run without debugging" still has some debugging process running

[gvcallen]

Type: Debugger

Additional context I have a Qt application and am using CMake and the CMake Tools extension to manage it. In my launch.json file, I am using the CMake Tools command "${command:cmake.launchTargetPath}" to populate the "program" variable, however it should be noted that the problem stated below occurs when this extension is disabled and this path is manually entered. The problem also occurs when my target has been created in both "release" and "debug" modes.

Describe the bug

• OS and Version: Windows_NT x64 10.0.18363
• VS Code Version: 1.46.1
• C/C++ Extension Version: 0.28.3

When double-clicking on my output executable from windows explorer, my console window appears and almost immediately afterwards my Qt Window appears. However, when running the command "Run: Start without debugging", the console window appears immediately as usual, however the Qt window takes around 4-5 seconds to appear, with constant action in the debug console. This indicates that there is still some debug process running, and that the executable is not simply being launched by the extension as expected.

To Reproduce

1. Create "heavy-weight" CPP project, in this case a Qt project
2. Run the command to start without debugging and notice that debugging process is still running
3. Run executable directly from windows and notice that debugging process is not running

Additional information I have attached my launch.json file below,. I also tried to include logging information, however my output console did not have the "C++ extension" option in the available outputs. I tried selecting "Log (Extension Host)" however this information is not recent log information from the extension.

Launch.json { "version": "0.2.0", "configurations": [ { //"program": "${command:cmake.launchTargetPath}", "program": "${workspaceFolder}/build/MinGW-8.1.0-64-bit/release/my-project/bin/my-project.exe", "name": "(gdb) Launch", "type": "cppdbg", "request": "launch", "args": [], "environment": [], "logging":{"engineLogging": true, "trace": true, "traceResponse": true}, "stopAtEntry": false, "cwd": "${workspaceFolder}", "externalConsole": true, "MIMode": "gdb", "windows": { //"miDebuggerPath": "C:/mingw/${command:cmake.buildKit}/bin/gdb.exe" "miDebuggerPath": "C:/mingw/MinGW-8.1.0-64-bit/bin/gdb.exe" }, "linux": { "miDebuggerPath": "/usr/bin/gdb" }, "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "visualizerFile": "c:\Users\gvcal\AppData\Roaming\Code\User\workspaceStorage\5fc1ddfdb3cacd826ef3a789b7fc84b6\tonka3000.qtvsctools\qt.natvis.xml" } ] }

[WardenGnaw]

The cpptools debuggers (cppvsdbg and cppdbg) do not support run without debugging.

We ignore the noDebug boolean in LaunchRequestArguments. We will just start a debug session.

This wil need to be implemented.

[gvcallen]

Oh wow okay - I read something about that in old issue but I had gathered that it had been fixed?

I definitely think this is extremely important - the ability to quickly execute your file without the debugger is a most have for anyone that is prototyping their software.

Furthermore, it might prevent C++ programmers from other IDEs switching over if features like this are missing.

Would it not be as simple as executing the "program" variable when that command is fired? I wouldn't mind giving it a look myself

[WardenGnaw]

Unfortunately we support launching the debugger on another machine via pipeTransport or communicate with it with a server with miDebuggerServerAddress or debugServerPath. See Remote Debugging Configurations. So if a user has a configuration with these remote debugging configurations, we should support launching on the remote machine without a debugger, too.

We do have the value of noDebug but it was only used for the old C# debugger clrdbg.

[Trass3r]

The only workaround is to use "stopAtEntry": true, and then run -exec detach in the debugger console.

[alanlivio]

@WardenGnaw, this feature will be very nice.

@Trass3r, I was not able to use the workaround.

This is my launch.json based in the template .

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(gdb) Launch",
      "type": "cppdbg",
      "request": "launch",
      // Resolved by CMake Tools:
      "program": "${command:cmake.launchTargetPath}",
      "args": [
        "/Users/alan/dev/ginga/ginga/examples/primeiro-joao/00syncProp.ncl"
      ],
      "stopAtEntry": true,
      "cwd": "${workspaceFolder}",
      "environment": [
        {
          // add the directory where our target was built to the PATHs
          // it gets resolved by CMake Tools:
          "name": "PATH",
          "value": "$PATH:${command:cmake.launchTargetDirectory}"
        },
        {
          "name": "OTHER_VALUE",
          "value": "Something something"
        }
      ],
      "externalConsole": true,
      "MIMode": "gdb",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        }
      ]
    }
  ]
}

[mathiaspalm]

For anyone else ending up here. Gathering various solutions I ended up with this that works ok. "stopAtEntry": false, "setupCommands": [ { "text": "source ${workspaceRoot}/.gdbinit" } ]

And then a .gdbinit with

set breakpoint pending on break main commands detach quit end

[sagian2005]

I tried to simply run a small test program without the debugger in C++ and I couldn't. I couldn't complete the most basic task with the simplest expectations. How is this useful?

[endolith]

The cpptools debuggers (cppvsdbg and cppdbg) do not support run without debugging.

Then shouldn't that option be grayed out?

[sagian2005]

The option should work. It makes absolutely no sense to not be able to do such a simple thing. It's maddening that it's still like this after more than two years.

[Aspirisha]

This is really sad. More than two years have passed, the problem is still present, and the basic functionality which seems to be obvious for any IDE, is still absent.

[mzient]

I don't understand how can this be still open after years. For someone with the development environment for this extension already set up, implementing this should be very simple - everything is already there (the command line, working directory, etc) - the only thing that needs to be done is to just launch the program and forget. Debugger does interfere a lot with program execution and having it attached e.g. in benchmarks or programs that communicate with some real-time hardware is not an option. Resorting to launching the program manually and retyping launch arguments (when I already have the launch configurations) is rather silly.

[sagian2005]

I would like to see this addressed with some sort of response; preferably something along the lines of, "We hear you. We're working on it." I can't believe it takes two years to figure out how to not run the debugger. How do we escalate something like this?

[mzient]

Bumping up! This is basic functionality. It's been requested multiple times. There are even several open issues with it! Can something finally be done with it? It's been over five years from the original request #1201 and this basic feature is still missing!

[Michal-Hubert]

👍 I am about to switch from CLion but it looks like major flaw not to have an easy way to launch something without any debugging at all.

[Tommimon]

I agree is sad that this basic feature is still not implemented.

In case somebody doesn't know there is a simple workaround:

• Go in Run and Debug tab
• Open BREAKPOINTS section
• click on Toggle Activate Breakpoints

This will run the program without breakpoints so it will never stop until the end.

Note that this is not the same of running without a debugger but until they implement the feature, we can't do much more.

[mzient]

Another year has passed - bumping up!

[dag10]

After tons of Googling just now I hit this thread as a dead end. Pretty frustrating.

[sagian2005]

After tons of Googling just now I hit this thread as a dead end. Pretty frustrating.

Yeah. We're now FOUR years without so much as an acknowledgement.

I gave up on VSCode for a number of reasons, but the lack of 'fixing basic functionality' while adding unwanted 'features' was the major impetus.