Vscode-cpptools: Debugger does not launch nor attach properly

[LFishi]

I am using:

• Ubuntu 16.04 (I know it is not supported officially)
• Latest VSCode version
• Latest "C/C++ for VSCode" version

My project structure looks like this:

• /home/lvier/mainProject/fooProject (source code)
• /home/lvier/mainProject/build/fooProject (binaries)

I am working in the sub-project "/home/lvier/mainProject/fooProject" and in "/home/lvier/mainProject/build/fooProject" there are many sub programs (lets say "foo", "foo_sub1", "foo_sub2" ...).

My goal:
I want to start the program "foo" (which starts all other foo_sub-programs) and then, I want to debug a certain sub program (let's say "foo_sub1") by attaching to it. I am also fine with starting and debugging in the same time as long as I can debug the sub-program "foo_sub1". The main project itself does not contain any executables.

Some months ago, debugging was working with "attach". For me it is not working anymore(because of VSCode updates and/or C/C++ extension updates). Here are my problems:

1. Assume that "foo" is running.
   When using the "C++ Attach"-config and setting "request": "attach" (which is getting highlighted as "not an accepted value"), it will ask for the property "processId" if it is not set. If I set "processId", the error "Attach not supported" pops up.
   If I use the "C++ Attach"-config with "request": "launch" (in the beginning this was autogenerated by the C/C++-extension), then the program finds the process id, tries to attach but then aborts with the message "Unable to start debugging. Commands are only accepted when the process is stopped." - what a surprise.
2. Assume that "foo" is not running yet.
   When using the "C++ Launch"-config, the program starts but no UI elements appear. Instead, it starts with a new terminal popping up which says "warning gdb failed to set controlling terminal operation not permitted" for a brief moment and in the internal console of VSCode, it states that it stops at a certain line of code (a breakpoint not defined by me) and prints
   "Stopped due to shared library event (no libraries added or removed)
   Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.
   [Thread debugging using libthread_db enabled]
   Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1"."
   From there I can't continue further and I have to manually terminate the program.

When I use GDB without VSCode, i.e. just by native terminal, my program is starting properly but with VSCode, there seem to be some issues currently.

This is my current, autogenerated config where I only edited the "cwd" and "program" paths (assume that the environment variable "${env.build_foo}" is set to "/home/lvier/mainProject/build/fooProject"):

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "C++ Launch",
            "type": "cppdbg",
            "request": "launch",
            "targetArchitecture": "x64",
            "program": "${env.build_foo}/foo",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceRoot}",
            "environment": [],
            "externalConsole": true,
            "linux": {
                "MIMode": "gdb"
            },
            "osx": {
                "MIMode": "lldb"
            },
            "windows": {
                "MIMode": "gdb"
            }
        },
        {
            "name": "C++ Attach",
            "type": "cppdbg",
            "targetArchitecture": "x64",
            "request": "launch", // <-- "attach" is not allowed (anymore)! :(   
            "program": "${env.build_foo}/foo_sub1",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceRoot}",
            "environment": [],
            "processId": "${command.pickProcess}",
            "externalConsole": false,
            "linux": {
                "MIMode": "gdb"
            },
            "osx": {
                "MIMode": "lldb"
            },
            "windows": {
                "MIMode": "gdb"
            }
        }
    ]
}

So far I am really frustrated and still don't want to give up on VSCode (I don't want to switch to another IDE yet). I have searched a lot for other issues and also tried to set some other config-properties but none of it helped. Does anyone else also have such issues with the debugger or is this a general problem with the extension (... and Ubuntu 16.04)?
I am happy for any help or convenient workaround. Thanks in advance!

Note:
I have also created a thread on stackoverflow (see http://stackoverflow.com/questions/38592017/vscode-debugger-for-c-does-not-launch-nor-attach-properly)

[delmyers]

@jacdavis Can you take a look at this?
@LVier What version of gdb are you using?

[LFishi]

The latest version:

GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word".

[jacdavis]

@LVier, I'm setting up a 16.04 machine now to see if I can repro this on attach. Any chance you can share your project with me?

[LFishi]

@jacdavis: I have to consult this with my supervisors because this is a student project with an own implemented framework. Currently, I guess they will not allow me to do so - I can find out more on this thursday.

Otherwise: What is with creating a blank C/C++ project - are you able to use the request-type "attach" or does it also say "Attach is not supported"? (I didn't try out yet because of lack of motivation)

[jacdavis]

Attach appears to be working fine for me on a basic app in Ubuntu 16.04. I'll try a dynamically loaded shared lib or use some threading libraries and see if that repros the issue you are seeing "Commands are only accepted when the process is stopped".

Also, as an aside, the request type for attach is supposed to be "launch". You shouldn't change this value to attach. The key to making it attach is to set the processId field to either pickProcess or to the processid. We might be able to change this in the current release, but in our earlier releases there were issues with using the request type "attach". So, we enabled it using an optional field in the launch config.

[jacdavis]

Okay, with a background thread created in the debuggee, it looks like I can repro this issue.
Thanks a lot for reporting this. I'll continue to investigate.

[LFishi]

That's what I guessed, so I changed the request type back to "launch".
What I would prefer for the attach handling:

• Setting the "processId" with "pidof ". In my case "processId": "pidof foo_sub1". It would be so much easier by doing so
• If the terminal does not ask me everytime, if I want to start gdb as superuser (and then after answering "Yes" prompting for PW).

What do you say?

Thanks for feedback so far, glad I was able to help with my report :)
I guess there is no workaround for me in the meanwhile?

[jacdavis]

"I guess there is no workaround for me in the meanwhile?" - not sure yet. I'm still investigating.

[jacdavis]

A change was recently made to detect the debuggee target architecture automatically. This check was not done properly and is getting rejected because the debuggee is in run mode when it executes on 16.04 attach with a thread created. Because this happens during the initialization phase, the engine shuts down the debug session.

As of right now, I don't think there is a work around. I'll keep you posted as I continue looking into this.

[LFishi]

Btw, when I set "cwd" to "${env.build_foo}" then I can launch the program with vscode even though the debugger behaves as before and furthermore, no mapping to source file exist now. Of course this may not be intended but I just wanted to mention it.

[delmyers]

@LVier, we checked in and released a fix. Can you try updating your extension, and let us know? Thanks.

[LFishi]

Yes and no:
I can confirm that my first problem with the "C++ Attach"-config has been solved, thank you for this fast fix!
But my second problem with my "C++ Launch"-config I mentioned in my original post is still not working yet (same behavior as in the original post). Therefore I am not sure if this issue should yet be marked as "closed".

Furthermore, the following notes may be different "issues" but they are kinda related and maybe it ain't a big deal:

• Again I repeat from my comment before:
  
  I am missing an extra property like "processName" (not processId!) as a default process name to attach to. I appreciate your recent update with "command.pickProcess" but in addition I would be happier to be able to set a default process name property. What do you think about this one?
• When attaching to a process, a terminal that pops up and asks for superuser rights - I guess the solution here for making it not ask for superuser rights has to be found outside of the C/C++ extension, right? Unfortunately, I haven't found one yet...

My user story that sums up the above would be:
"When I press debug (attach), I want to start immediatly with debugging and I don't want to be prompted for anything (i.e. not picking process, not pressing "y" for permitting superuser rights and no password entering)."

What do you say?

[jacdavis]

Thanks for verifying the attach fix. We can't repro the launch issue with the debuggees we have used. Did you get a chance to speak to your supervisor about sharing the repro?

As for attach not prompting, if you install vscode as root, and give rights to vscode to debug, then you will not get prompted. Unfortunately in Linux, most attach scenarios require root permissions (unless the attach process is already a child process of the debugger).

[LFishi]

Thanks for the forking and further provided answers.
Unfortunately, no, I somehow forgot to ask again. I can write an email these days and see what they will respond.

But the following note from my last answer still seems overlooked if I checked your answers right:

Again I repeat from my comment before:
I am missing an extra property like "processName" (not processId!) as a default process name to attach to. I appreciate your recent update with "command.pickProcess" but in addition I would be happier to be able to set a default process name property. What do you think about this one?

[baloodevil]

I am having the same issue of debugger not attaching properly to a multithreaded C++ app, so breakpoints are not hit, using...

• Ubuntu 16.04
• Latest VSCode version
• Latest "C/C++ for VSCode" version
  I can share my project. Please send a message with an email address to send it to. Thank you!

[HorstBaerbel]

Same issue here. Project is here https://github.com/HorstBaerbel/compress
I imported the CMake project. It builds and I can start it from the command line. Not sure if my launch.json is correct, as I'm pretty new to VSCode:

{
"version": "0.2.0",
"configurations": [
{
"name": "C++ Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/cmp5",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceRoot}",
"environment": [],
"externalConsole": true,
"linux": {
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
"osx": {
"MIMode": "lldb"
},
"windows": {
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
},
{
"name": "C++ Attach",
"type": "cppdbg",
"request": "attach",
"program": "${workspaceRoot}/cmp5",
"processId": "${command:pickProcess}",
"linux": {
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
"osx": {
"MIMode": "lldb"
},
"windows": {
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
}
]
}

I set a breakpoint at the very top of main(). The debug output is:

License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Stopped due to shared library event (no libraries added or removed)
Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.
Breakpoint 1, 0x0000000000418210 in main ()
[Inferior 1 (process 7027) exited with code 0377]
The program '/PATH_EDITED/compress/cmp5' has exited with code 377 (0x00000179).

[HorstBaerbel]

So... Debugging works for me now after I removed the GCC -s flag (strip symbol table and relocation information) from the linker settings in my CMakeLists file. Probably GDB couldn't attach to the process because the symbols were stripped (or attached and quickly detached again).
Running "gdb " from the command line results in the message "Reading symbols from ...(no debugging symbols found)...done.", which is a bit more useful than what is generated when launching via VSCode. When GDB finds symbols it states "Reading symbols from ...done.".
I'm not sure if there's a way to check if GDB has loaded symbols. When I try "maint info symtabs " in the stripped binary, the output is empty, but there is information output with the executable containing symbols, so maybe this could be used to check if launching worked.