I am wondering if GoLand can use the dlv exec command for debugging.
The reason we need this is because we have a complicated build process with CGO, and it's impossible to create a run configuration that works.
Maybe attach to process could work, but it doesn't seem like a great solution.
VSCode has nice integration with dlv exec, but the IDE works too slow and buggy, I wish we could use GoLand.
Has anybody found a solution for this?
Thanks in advance.
You can use the same steps as in debugging a remote process.
Those steps are:
build the binary with go build -gcflags="all=-N -l" -o myApp and any other flags you might need for CGO/etc.
run the binary using dlv --listen=:2345 --headless=true --api-version=2 exec ./myApp
go to Run | Edit Configurations | + | Go Remote and create a new run configuration that connects to localhost on port 2345 (or any other port you specify in delve's --listen flag.
Related
The title mostly says it. I know that I can do
set GOOS=linux
set GOARCH=amd64
in cmd before I go build, but I'm trying to write a build script and do it all with exec.Command.
My go build -o etc works with exec.Command (it builds), but when printing out GOOS in a test script after either of this commands:
cmd := exec.Command("set", "GOOS=linux")
// OR
cmd := exec.Command("set GOOS=linux")
I get windows.
Any ideas? Thanks!
I strongly suggest you just use a tool like Gox instead. It cross-compiles into every supported build target by just executing gox. It also has options if you only want to build for certain targets.
As for the code you're asking about, exec.Command doesn't create a new process, or really do anything other than create a Cmd struct. The os/exec documentation (specifically the docs for the Command function) has an example of what you seem to be trying to do- execute another program with custom environment variable assignments... see the Example (Environment) section of the linked documentation and try to follow that structure if you still want to cross-compile your way.
I encountered the problem that I wanted to have a debug, then I wanted to build a debug version of tensorflow, using the following command:
bazel build --compilation_mode=dbg -s //tensorflow/tools/pip_package:build_pip_package
but it will trigger the longtime link in protobuf for almost oneday, and still not finished.
and my intension is to build some other package which is used by tensorflow with debug mode, could I configure the bazel build file to get some debug package separately?
To understand the issue better, try running the neverending action manually:
start the debug build, wait for it to get stuck in the protobuf linking action
interrupt the build (Ctrl+C)
run the build again with the -s flag, so Bazel shows the command line it executes (you could've ran step 1. with the -s flag, but then there's a lot more output and it's harder to find the right information)
interrupt the build again
cd into the directory shown in the by command and set environment variables
try running the command that failed (you may need to change the output paths because they are sometimes not user-writable) and see if it still never finishes
What you just did is running the same command Bazel was running and getting stuck on. If the command is stuck in this manual mode too, then the error might be with the linker (I doubt this is the case though). But if it succeeds, then the problem is with Bazel.
I have latest IntelliJ Ultimate EAP and latest Gogland and the problem occurs on both under MacOS Sierra.
I'm trying to debug a go application by creating a debug profile for Go Application and the Run Kind is configured to Package, which contains the package name of the current project.
under Go tool arguments I have -ldflags="-linkmode internal" configured.
When I start a debug session while having some breakpoints, it would run but not stop at these breakpoints.
what am I missing?
thanks
update
ok I was able to reproduce the issue with the following project:
test1.go contains:
package main
const Numb uint64 = 5
test2.go contains:
package main
import "fmt"
func main() {
fmt.Println(Numb);
}
I Created a Go Application run/debug configuration with the following parameters:
Run kind: package
Package: github.com/kfirufk/test
Working Directory: /usr/local/Cellar/go/1.8.1/src/github.com/kfirufk/test/
when I choose a breakpoint on test2.go line 6 (the first and only line of code in the main function) and I start a debug session, I see the following output:
"/Users/ufk/Library/Application Support/IntelliJIdea2017.1/Go/lib/dlv/mac/dlv" --listen=localhost:53111 --headless=true exec /private/var/folders/cn/n7rwdd_95_l54s3zdnbxvw040000gn/T/Unnamedgo --
GOROOT=/usr/local/Cellar/go/1.8.1/libexec
GOPATH=/usr/local/opt/go
/usr/local/Cellar/go/1.8.1/libexec/bin/go build -o /private/var/folders/cn/n7rwdd_95_l54s3zdnbxvw040000gn/T/Unnamedgo -gcflags "-N -l" github.com/kfirufk/test
API server listening at: 127.0.0.1:53111
5
I get the program's output properly but Intellij did not stop in the required breakpoint.
the problem is reproduced on Intellij 2017.1.3 with Go Lang Plugin 0.171.1928 on MacOS Sierra 10.12.4.
update
trying to play with intellij's delve to try to understand better what's going on:
/Users/ufk/Library/Application\ Support/IntelliJIdea2017.1/intellij-go/lib/dlv/mac/dlv exec ./test
then I executed:
(dlv) step
and received:
Command failed: could not find FDE for PC 0x78bc000
did I fail to understand how to use delve or is something doesn't work properly here ?
update
yeap.. with continue the debugger works properly with both versions of delve (installed from homebrew and the intellij's version). but still intellij works the same, doesn't stop at breakpoints. i create a breakpoint at test2.go at the line when I print the variable.
any ideas ?
Ok.. I finally got it. I got mixed up with the GOROOT structure and GOPATH structure and I placed my project in GOROOT instead of GOPATH.
this is what I did to resolve the issue
I completely deleted go with brew uninstall --force go, then reinstalled go with the following environment variables:
export GOPATH=$HOME/golang
export GOROOT=/usr/local/opt/go/libexec
export PATH=$PATH:$GOPATH/bin
export PATH=$PATH:$GOROOT/bin
then I placed my project at ~/golang/src/github.com/kfirufk/windy-server
and I was finally able to properly debug go applications.
thank you all for assisting me! :)
For my case (VSCode on Ubuntu 20.04), if the project is inside a symbolic link directory (or sub-dir of a symbolic dir), vscode will shows "unverified" breakpoints and
"Error on CreateBreakpoint: could not find file ..."
which leads to not stop on breakpoints.
cd \`readlink -f <project dir>\` && code .
will be ok.
For me, issue resolved adding:
export GOROOT="/usr/local/go"
to $HOME/.profile.
EDIT:
I'm using LiteIde X35.2, with Delve Debugger
Version: 1.1.0
Build: $Id: 1990ba12450cab9425a2ae62e6ab988725023d5c $
under:
DISTRIB=LinuxMint VERSION=18.3 CODENAME=sylvia
RELEASE=#41~16.04.1-Ubuntu SMP Wed Oct 10 20:16:04 UTC 2018
UBUNTU_CODENAME=xenial KERNEL=4.15.0-38-generic HDWPLATFORM=x86_64
DESKTOP_SESSION=XFCE WINDOWS_MANAGER=XFWM4
DESKTOP_COMPONENTS=kdevtmpfs gnome-keyring-d xfce4-session xfce4-panel
xfce4-volumed polkit-gnome-au xfce4-power-man xfce4-terminal
gnome-pty-helpe
GTK=libgtk-3-0:amd64 3.18.9-1ubuntu3.3 GStreamer=gst-launch-1.0
version 1.8.3 GStreamer 1.8.3
https://launchpad.net/distros/ubuntu/+source/gstreamer1.0
In my case, the process was already running at that port and didn't close. So I had to manually stop the process and run again from IntelliJ.
In my case (GoLand), the problem was with the flag -trimpath not being set in my debug configurations:
"Run", "Debug...", "Edit Configurations."
In the templates item, go to "Go Test" option and add the argument -trimpath in "Go tool arguments"
You can also set in your environment with:
go env -w GOFLAGS="-trimpath"
That also works for the "attach to process" debugging option.
You can see GoLand IDE Logs in the menu "Help", "Show Log Files". It will make your life easier.
Reference: https://youtrack.jetbrains.com/issue/GO-8277
I have some go tests. I would like to debug with gdb.
But the binaries built by go test are thrown away after running.
So how do I do it?
go 1.6 on windows/64
You use go test -c which will produce the executable file xyz.test. Afterwards you use gdb xyz.test to debug.
Just check go test --help for an explanation of the -c flag:
Compile the test binary to pkg.test but do not run it
(where pkg is the last element of the package's import path).
The file name can be changed with the -o flag.
I would like to learn how to make a text editor using GTK+. I think the best way to do this is to watch what is happening in the code when one runs Gedit. I have been told that one has to compile the sources of Gedit and GTK+ for -g option. But as I am a very beginner of open source world, I would like to know
How can I load the sources of GTK+ and Gedit to my computer?
How to compile them to one package which can run on debugger?
How to run the Gedit and debugger so that I can see what is going on when one runs the program?
I'm using Ubuntu 10.04. I haven't done debugging earlier so I thought that DDD or Nemiver would be the easiest to learn but any suggestions are welcome.
For Ubuntu, simply do:
cd ~/Desktop # or wherever you want it
apt-get source gedit # does not need sudo
Check the README / INSTALL files - they should give you plenty information about compiling, just adapt the instructions to your needs. For a simple compile it's just:
./configure
make
The GEdit main development page is at: http://git.gnome.org/browse/gedit/
You can get the upstream source code using git clone git://git.gnome.org/gedit
You should use ./configure --enable-debug so it contains debug information in the first place (usually, C executable don't which is why they are so small).
So to correct the above from what you have now:
make clean
./configure --enable-debug
make
In DDD, F5 is step, F6 is next, F8 is finish and you can set breakpoints.