I run a process inside a docker container that needs to be debugged. The process is started in the docker's entry point via
dlv debug /go/src/path/to/package --headless --listen=:2345 --log for the purpose of enabling debugging later in VSCode.
The docker container is started via
docker run --rm -it -p 2345:2345 my_image:tag. Note delve's port is exposed.
In VSCode I define launch.json as follows:
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach remote",
"type": "go",
"request": "attach",
"mode": "remote",
"port": 2345,
"host": "127.0.0.1",
"apiVersion": 1
}
]
}
Upon starting the "attach remote" VSCode debugging configuration I get
It isn't crystal clear, but that UI leads me to believe I'm now connected to the remote headless debugger and ready to debug. I have one breakpoint defined which I know would be hit by a request I can send the remote process. I send that request, I get a result, and that breakpoint never hit, indicating that I haven't yet achieved remote debugging.
Is something wrong with my VSCode "attach remote" configuration? I can do command-line debugging with dlv connect :2345 and actually debug the remote process just fine, which indicates the headless server is functional. I would rather debug with source code, in VSCode though.
Try again with the latest beta of vscode-go (April 2020) (for any time after April 2020, the latest official vscode-go release will be enough)
Microsoft/vscode-go issue 2010 includes this confirmation from Ramya Rao:
The fix from #3108 is available in the latest beta version of this extension. Please do try and share feedback
The latest version of the extension now has the fix to this issue
And:
I can confirm that I am able to hit breakpoints now using AWS SAM to launch a linux container with delve and go binaries compiled from Windows.
For anyone still having this problem (like I was before I edited this comment), take care that the "remotePath" element of your launch.json is the absolute path to the source files as compiled on your local system (not the container).
As implied above - it's the absolute local path that is added to the DWARF compilation unit file table when you compile the binary.
Related
How can I debug while using --host option on Vue 3 Vite so I can debug my phone instance for example. At the moment Im using visual studio code plugin "Vite"
launch.json:
{
"version": "0.2.0",
"configurations": [
{
"type": "pwa-chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:4000",
"webRoot": "${workspaceFolder}/app",
}
]
}
package.json
"scripts": {
"dev": "vite --host --port 4000",
}
Vite config options
with this I'm being able to run on lan and debug but only on my pc, if I try from my phone or other pc, it connects but it wont stop on any breakpoint.
In order to debug any web app, web browser running on your phone must support a debugging protocol. Chrome for Android for example does support what you need, see Remote debugging article.
As for another PC, you need to launch Chrome there with a remote debugging command line switch as well, and then edit your launch.json to attach your vs code instance to different host (ip and port). That is of course if you want to be able to set breakpoints in vs code on your developer machine and then reflect that on another PC.
Roughly saying, you need to point your vs code to a running target
browser, for example, in your current config vs code launches instance of Chrome with a debugging switch enabled for you, behind the scenes
Visual studio can create a project from template with "enable Docker support". In which a section in launchSettings.json is created with
"Docker": {
"commandName": "Docker",
"publishAllPorts": true
}
When started with this configuration, what I see is that docker image is built and started in Docker Desktop and debugging is started in a remote debugging fashion (I see no dotnet instance started locally)
My question:
Are my assumptions correct?
Is there any documentation that describe thoese behaviour and where we can tweak these settings, such as targeting a remote docker host?
How can I force Delve in VS Code to use root privileges?
I'm trying to debug go file that involves gopacket/pcap:
hndl, err := pcapgo.NewEthernetHandle(ifname)
// err == "couldn't open packet socket: operation not permitted"
Launching same program using sudo doesn't trigger error.
I've tried several methods:
Launch sudo code . It warns that it is not recommended. Plus there are issues to use dlv in this mode as environment variables are messed up.
Using this guide https://fatdragon.me/blog/2020/06/debug-golang-vs-code-linux-root. However "go.alternateTools" seems to know nothing about "dlv": Property dlv is not allowed. Probably something is missing in guide.
Search for .vscode/launch.json config property that allows to sudo. VSC allows to do such for Python, but not for Go.
Is there any trivial way to launch debugger with root privileges?
Environment:
Ubuntu 18.04
VSCode 1.48.0
Go 1.13.4
Delve 1.4.0
Update May 2022
Debugging programs and tests as root in the documentation of the VSCode Go addon has been updated accordingly with task and launch configuration examples to not only debug programs but also tests as root.
Old
Debugging Go programs and tests that require root privileges using VSCode has been sore for a long time. As of VSCode version 1.65.0 I noticed a new experimental launch option "asRoot": "true" 🙌 that needs to be combined with "console": "integratedTerminal".
For instance, in your launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Test/dbg pkg as root",
"type": "go",
"request": "launch",
"mode": "test",
"program": "${fileDirname}",
"console": "integratedTerminal",
"asRoot": true,
},
]
}
When launching this configuration by pressing F5, a new debug terminal session opens (or might get reused) and the following command executed:
/usr/bin/env GOPATH=/home/foobar/go /usr/bin/sudo /home/foobar/go/bin/dlv dap --check-go-version=false --client-addr=:41945
This now automatically inserts the sudo command before dlv itself, so this needs to be launched into an internal or external interactive terminal (and thus does not work in the internal console). After authenticating to sudo, VSCode switches back to the debug console view and you are good to go.
This now avoids having to fiddle around with remapping the dlv command in your workspace to a wrapper shell script.
I have the following entry in project.json:
"commands": {
"web": "Microsoft.AspNet.Server.Kestrel"
}
I have until now been running 'dnx web' on the command line to start up my server. However, I would like to start it in such a way that I can debug (i.e. execution will hit the breakpoints that I set). How can I do this?
Thanks in advance.
Make sure your startup project of your solution is pointing at a project that can be started by one of the commands you have in project.json. If it is, then the command will appear in the start menu at the top of visual studio so that you can start it in debug mode.
Is it possible to debug a uwsgi application using an ide like PyCharm? I can debug flask based apps fine by running them directly from pycharm but cannot even run a uwsgi app from within pycharm.
Do I have to use remote debugging? Is it possible to start a uwsgi app from within pycharm using run?
You can still run your WSGI app outside of uWSGI for development and debugging purposes.
However sometimes this is not possible, for example if your app relies on uWSGI API features.
As far as I know you can't use "Attach to Process" from PyCharm because your WSGI app is running embedded into uWSGI, and there are no visible Python processes. Remote debugging however works like a charm.
Locate pycharm-debug*.egg files in your PyCharm distribution. For example, on OSX both can be found in /Applications/PyCharm.app/Contents
Copy pycharm-debug-py3k.egg next to your Flask app, or copy pycharm-debug.egg instead if you are using Python 2.7
In PyCharm, create a "Python Remote Debug" configuration from "Run/Debug Configurations" dialog. In this example I use localhost and port 4444. This dialog will show you the corresponding pydevd.settrace(...) line.
Add the following code to your app :
import sys
sys.path.append('pycharm-debug-py3k.egg') # replace by pycharm-debug.egg for Python 2.7
import pydevd
# the following line can be copied from "Run/Debug Configurations" dialog
pydevd.settrace('localhost', port=4444, stdoutToServer=True, stderrToServer=True)
In PyCharm, start the remote debugging session. PyCharm's console should display the following line :
Waiting for process connection...
Run your app from uWSGI as usual. It should attach to the debugger, and PyCharm's console should display :
Connected to pydev debugger (build 139.711)
Your app should break on the pydevd.settrace(...) line. You can then continue and use PyCharm debugger as usual (breakpoints and so on)
Not sure how to interpret your question, as you are mixing apples and oranges. Flask is a framework, uWSGI is an application server. I'll try to answer, though.
As far as I know, uWSGI is not pure python, so debugging it in PyCharm will not be trivial, if even it is possible.
However, since you are using uWSGI to run your application, I'm assuming it complies with the WSGI protocol. In that case, for debugging purposes, you can alternatively run it from a simple pure-python application engine like wsgiref.simple_server.WSGIServer.
There is now an official guide on how to do this:
https://www.jetbrains.com/help/pycharm/remote-debugging-with-product.html#
If your code already exists in remote, you only need to follow Create a run/debug configuration
You'll need the IP where the PyCharm is running. When you run the remote debugger from PyCharm, it'll create a debugging server. Your code will connect to this server.
In my case, I'm using Vagrant, with private IP of the guest 192.168.0.3, and the host's private IP is 192.168.0.1.
My code in the remote guests will connect to the debugging server through the host IP. So I need to use my host IP in the code that I want to debug.