Open yamcenutzer opened 6 years ago
I tried to point the vscode guys to this issue: They closed it. https://github.com/Microsoft/vscode/issues/58091
@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
.
Here is the actual comment
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..
@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.
I'll try this weekend at home. out of office now..
Ok thank you!
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 .
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"
]
},
Yes that works, but not with sudo. I was debugging a service as sudo using a script containing:
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
oops, I pressed the close button
Can you attach to the process rather than launch it?
never tried, since I need to debug the startup
You can start a bash
process with your required privilege, attach to it, and use the exec
command
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.
https://github.com/Microsoft/vscode-cpptools/issues/2489#issuecomment-420123838 This is just telling VS Code to "remote debug" a local process
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
@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.
will do so as soon as i'm back from travelling (december)...
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).
@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.
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.
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:
when trying to strart debugging a window pops up: Unable to start debugging. Failed to initialize debugger terminal. To Reproduce a hello world cpp app try to debug it with standard launch.json:
"version": "0.2.0", "configurations": [ { "name": "(gdb) fbMon", "type": "cppdbg", "request": "launch", "program": "${workspaceRoot}/bin/x64/release/a.out", "args": [ "-s" ], "stopAtEntry": true, "cwd": "${workspaceRoot}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "/usr/bin/gdb", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true } ] } ] } Additional context
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:”
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.
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.
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?)