search

microsoft / vscode-cpptools

Official repository for the Microsoft C/C++ extension for VS Code.
Other
5.45k stars 1.53k forks source link

Centos/RHEL7: Unable to start debugging. Failed to initialize debugger terminal. #2489

Open yamcenutzer opened 6 years ago

yamcenutzer commented 6 years ago

Type: Debugger Input information below

Please review existing issues and our documentation at https://github.com/Microsoft/vscode-cpptools/tree/master/Documentation prior to filing an issue.

Describe the bug -Centos 7.3, 7.4, 7.5:

  1. reading through other, similar complaints I found that this might bew related to gnome-terminal. My use case is a remote ssh to the centos machine in question. vscode is run over remote ssh with X-forwarding. I tried launching gnome-terminal from my ssh console: that works. However, if try launching gnome terminal from inside the vscode terminal window, that fails with an error: Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Unknown or unsupported transport “disabled” for address “disabled:”

  2. I tried downgrading the cpp extension to 17.3 but that too isn't working. I have been using vscode on centos7 for quite a while now (since it first came out), with varying degree of success (glibc 2.17 issues, etc.) and the debugger did use to work. I admit I haven't debugged in awhile, so I can't say when this issue has crept in, but seems before 0.17.3.

  3. Update: As I was pretty sure I was debugging in May this year, I downgraded to extension V. 0.16.0 that didn't help. I had to downgrade vscode itself to 1.23 . That works also with the latest version of the extension (0.18.1). Now of course, all sorts of other things are broken.

  4. Working my way back up 1.24.1, 1.25.1, it shows that the problem appeared in the July version of vscode: 1.26.1. The question is, should this be reported/handled here or with the vscode people (who would that be?)

yamcenutzer commented 6 years ago

I tried to point the vscode guys to this issue: They closed it. https://github.com/Microsoft/vscode/issues/58091

pieandcakes commented 6 years ago

@yamcenutzer I think your comment that the extension fails is incorrect. You should point them to the comment that 1.23 + latest extension works fine but 1.26.1 + latest extension does not. That seems to be why they closed it.

Beyond that, I know a gnome-terminal update changed the executable in the bin folder to be a script calling the actual executable now which someone reported being a problem. They were able to work around it by renaming the script and then naming the executable gnome-terminal.

pieandcakes commented 6 years ago

Here is the actual comment

yamcenutzer commented 6 years ago

Let me summarize this differently:

cpp-tools debugging does not work on Centos7 when installed on top of vscode 1.26 or later. I don't know about other *IXEN, (esp. older ones from the 'enterprise' world with ancient glibc, gcc etc) but wouldn't be surprised if there are similar problems there. Centos/RHEL is not exactly a rarity in the real world.

If I set up a new Linux (Centos) machine today (just doing it), and install the cpptools extension, I won't get a working debugger. The vscode people have understood that there was a change in the terminal between 1.25 and 1.26 and they were adamant that any debugger extension needs to adapt..

pieandcakes commented 6 years ago

@yamcenutzer Can you confirm the issue is that gnome-terminal is a python script and that is the problem? I'm working on supporting the VS Code style terminal which should remove this dependency but if that is the problem, it might be something we can try and fix quickly.

yamcenutzer commented 6 years ago

I'll try this weekend at home. out of office now..

pieandcakes commented 6 years ago

Ok thank you!

yamcenutzer commented 6 years ago

installed a new centos7 in a VM (it really is easy on a win10 hyperv, no hitches, gen2 and go).

update: I found an old pc and installed C7 on it to test vscode run natively (not over ssh/X). Apart from everything GUI being faster (obviously) the debugger does run there. So it seems to be related to ssh connections, which, TBH, is the default use case for *XEN in my world.

However, as I said earlier, the ssh use case, apart from being painstakingly sluggish, did use to work in earlier versions .

amtlib-dot-dll commented 6 years ago

Workaround: Add this snippet to your launch.json and the internal terminal of VS Code will be used instead

"pipeTransport": {
    "pipeCwd": "/usr/bin",
    "pipeProgram": "/bin/sh",
    "debuggerPath": "/usr/bin/gdb",
    "pipeArgs": [
        "-c"
    ]
},
yamcenutzer commented 6 years ago

Yes that works, but not with sudo. I was debugging a service as sudo using a script containing:

!/bin/sh

sudo gdb $@

and in the launch.jsion using "miDebuggerPath': "pathtoscript"

I'll need to find out how another level of indirection can be added.

My current workaround is to fall back to vscode 1.25.1

yamcenutzer commented 6 years ago

oops, I pressed the close button

amtlib-dot-dll commented 6 years ago

Can you attach to the process rather than launch it?

yamcenutzer commented 6 years ago

never tried, since I need to debug the startup

amtlib-dot-dll commented 6 years ago

You can start a bash process with your required privilege, attach to it, and use the exec command

yamcenutzer commented 6 years ago

too far fetched. I was thinking, why do we even need a terminal? Visual Studio (not code) can remote debug a linux machine (not sure about sudo). I thought VsCode was using the same engine connecting to gdbserver.

amtlib-dot-dll commented 6 years ago

https://github.com/Microsoft/vscode-cpptools/issues/2489#issuecomment-420123838 This is just telling VS Code to "remote debug" a local process

amtlib-dot-dll commented 6 years ago

Yes that works, but not with sudo. I was debugging a service as sudo using a script containing:

!/bin/sh

sudo gdb $@

and in the launch.jsion using "miDebuggerPath': "pathtoscript"

I'll need to find out how another level of indirection can be added.

My current workaround is to fall back to vscode 1.25.1

Perhaps changing pipeProgram to sudo may do the trick, that is "remotely" run your executable via sudo rather than ssh

pieandcakes commented 5 years ago

@yamcenutzer Can you try with our newest version? The integrated terminal feature is available in our 0.20.0 version of the extension. To use the integratedTerminal, set externalConsole to false in your launch.json. I'm hoping that removing the requirement for a terminal app will allow it to work.

yamcenutzer commented 5 years ago

will do so as soon as i'm back from travelling (december)...

jarchca commented 5 years ago

I stumbled across this thread; I too am using CENTOS 7 and been using VS Code for 6+months. With latest update (1.29) debugger stopped launching. I tried both solutions: using externalConsole set to false in launch.json (that worked). The suggestion by amtlib-dot-dll also worked.

Both of these are hacks though; I still prefer that my console window work as before (i.e., externalConsole set to true in launch.json).

pieandcakes commented 5 years ago

@jarchca Can you clarify that launching doesn't work with the latest version of the extension? Are you also trying to sudo? You mention 1.29 but that's the VS Code version and not the version of the extension.

jarchca commented 5 years ago

The MSS C++ extension tool I am using is the latest 0.20.1 and no, I wasn't using sudo in conjunction with any of my debug sessions.