Attempting to use Delve to debug Go, I get the following error:
could not launch process: fork/exec C:\code\go_stuff\debugtest\__debug_bin: Access is denied.
could not remove C:\code\go_stuff\debugtest\__debug_bin: remove C:\code\go_stuff\debugtest\__debug_bin: Access is denied.
This is on a very simple Go project I created using go mod init and I wrote the main.go using Vim, so no VSCode or anything else is involved.
I tried to run dlv debug from the terminal and I get the above output.
I also get the above output when I try and debug using Delve in VSCode as well.
I have tried this on another PC and it works perfectly so it may well be something environmental but I cannot fathom what is causing this.
None of the projects I am trying to debug are in git or indeed any other source control.
Before I incur any downvotes due to lack of code, here is my entire project:
package main
import "fmt"
func main() {
fmt.Println("So we begin")
fmt.Println("Here we end")
}
It seems to be have been an issue caused by anti-virus deleting the executable when I tried to run it or even debug it.
I moved to developing Go in WSL2 using VSCode and I can debug the code without issue, so this would appear to be environmental and not an issue with either Delve or Go.
Actually I've met similar problem. I modify the "settings.json" file of VScode as following:
{
"workbench.colorTheme": "Default Dark+",
"workbench.editorAssociations": {
"*.ipynb": "jupyter.notebook.ipynb"
},
"gopls": {
"experimentalWorkspaceModule": true
},
"go.alternateTools": {
},
"go.delveConfig": {
"dlvLoadConfig": {
"followPointers": true,
"maxVariableRecurse": 1,
"maxStringLen": 64,
"maxArrayValues": 64,
"maxStructFields": -1
},
"apiVersion": 2,
"showGlobalVariables": false,
"debugAdapter": "legacy",
"substitutePath": []
}
}
Then try to debug or either run without debug. It works and the "__debug_bin.exe" will not generate anymore. However I don't know the reason, it seems some problem of dlv configuration. Does anyone know the root cause? Hope this help you!
Related
I've checked out the main branch of github.com/Shopify/sarama (at commit 947343309601b4eb3c2fa3e7d15d701b503dd491 ) but I notice that in VS Code I can't "Go to definition" as usual. If I hover over the package name sarama in functional_consumer_group_test.go, I get the linter warning
No packages found for open file /Users/kurtpeek/go/src/github.com/Shopify/sarama/functional_consumer_group_test.go: <nil>.
If this file contains build tags, try adding "-tags=<build tag>" to your gopls "buildFlags" configuration (see (https://github.com/golang/tools/blob/master/gopls/doc/settings.md#buildflags-string).
Otherwise, see the troubleshooting guidelines for help investigating (https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md).go list
(See screenshot below).
From the command line, if I try to gopls that file, I get a similar error:
> gopls check functional_consumer_group_test.go
gopls: no packages returned: packages.Load error
I suspect this has something to do with the build constraints (https://pkg.go.dev/cmd/go#hdr-Build_constraints) in that file, from https://github.com/Shopify/sarama/blob/947343309601b4eb3c2fa3e7d15d701b503dd491/functional_consumer_group_test.go#L1-L2,
//go:build functional
// +build functional
It's not clear to me, however, how to modify my VS Code settings.json to pass these build constraints. Does anyone know how to get this functional test to build?
Following https://www.ryanchapin.com/configuring-vscode-to-use-build-tags-in-golang-to-separate-integration-and-unit-test-code/, I had to create a .vscode/settings.json file in the repository's root directory and add the following contents:
{
"go.buildFlags": [
"-tags=functional"
],
"go.testTags": "functional",
}
Now VS Code works like normal in that file:
Have you tried go clean -cache?
And this link may help:
https://github.com/golang/go/issues/42353
This worked for me!
by adding it in .vscode/settings.json
{
"gopls.env": {
"GOFLAGS": "-tags=test"
}
}
Ubuntu. vscode 1.62.1. go1.17.3. vscode go extension v0.29.0. delve v1.7.1.
I'm new to vscode and Go. I have many years of experience debugging Java apps in Eclipse.
I've constructed a small multi-module Go app. I can set a breakpoint in main and other functions in other modules. Inside main.go, I select "Start Debugging".
It starts the application, and I can tell it's working from the console, and that the REST endpoint responds with my dummy response.
However, it will NOT stop at breakpoints. As soon as I start the session, the red breakpoint markers suddenly become hollow, and hovering on one of them shows a message "Could not find file ...", which prints the full path to the source file in question.
When I start it, it shows the following in the console:
Starting: /home/.../go/bin/dlv-dap dap --check-go-version=false --listen=127.0.0.1:43347 --log-dest=3 from /home/.../...
DAP server listening at: 127.0.0.1:43347
I haven't modified the launch.json (I hope someday a friendlier interface to editing launch configurations is provided).
What else could I be doing wrong?
Update:
This is a screenshot showing main.go just before I press F5 (Start Debugging):
Notice that I have a breakpoint on the print statement, on the first line of main.
This is what I see after I press F5:
Notice that it printed "At start of main" in the console. It didn't stop at the breakpoint. Also notice message in tooltip when hovering over the breakpoint.
Update:
This is a view of my directory structure:
First, just make sure you have initiated your project with go mod init voltagems: that would explain the import "voltagems/xxx", but also helps delve to find your main.go file at debug time.
You should have go.mod and go.sum files beside main.go.
Second, check your go env output, making sure GOPATH and GOROOT are set to default paths.
The OP David M. Karr adds in the comments:
I did run "go mod init" when I first created the project, but I realized that I didn't like the root module name, so I changed it to "voltagems"
I believe you can edit directly go.mod first line, and make sure it says:
module voltagems
Then go mod verify + go mod tidy
Finally, go build .. Restart your VSCode (or the command Reload Window), and see if the issue persists.
The OP David M. Karr points out to a root cause:
There are symbolic links in my project path.
There is a "substitutePath" configuration in VSCode-Go that is used to map to absolute paths.
You can see this parameter mentioned in Debugging with Legacy Debug Adapter
substitutePath
Path mappings to apply to get from a path in the editor to a path in the compiled program (default: []).
That comes from issue 622 "debug: breakpoints don't work when working with symlink".
And commit 93f32bb
src/debugAdapter: add substitutePath config for debugging
This change adds a new configuration option to both launch and
attach requests.
substituePath takes an array that maps from string to string that is used to translate paths passed to the debugger and then
back to the client.
This allows users to translate their symlinked directories to the
files that were actually used to build the binary.
In addition this can also be used for remote debugging, and when the location of the files has moved since the program was built.
Example: you need a from and to key:
"substitutePath": [
{
"from": "/symlink/path/dir/on/local/machine",
"to": "/absolute/path/dir/on/local/machine",
},
I'm using the tcell library to display terminal cell graphics.
While writing this project in GoLand, I've noticed that using a normal run configuration and running the program in the integrated terminal, I'm not seeing the cells getting set as intended, despite tcell not giving any errors.
Program:
package main
import (
"time"
"github.com/gdamore/tcell"
)
func main() {
screen, err := tcell.NewScreen()
if err != nil {
panic(err)
}
err = screen.Init()
if err != nil {
panic(err)
}
screen.SetCell(0, 0, tcell.StyleDefault, 'X')
screen.SetCell(1, 0, tcell.StyleDefault, 'X')
screen.SetCell(1, 1, tcell.StyleDefault, 'X')
screen.SetCell(10, 10, tcell.StyleDefault, 'X')
screen.Show()
time.Sleep(time.Second*5)
}
GoLand output:
The program works as expected when running through cmd:
How can I set a run configuration in GoLand to run my program in cmd, or some other form of terminal that will allow me to set cells like this?
Open Help | Find Action...
Type Registry and hit Enter.
Find go.run.processes.with.pty there and turn it on.
Please, keep in mind that it can cause problems with run configurations like failing green tests or vice versa, never finishing debug sessions, and so on. If you notice weird IDE behavior related to console output, please disable the registry option back.
I'm not sure if points on Y-axis do display properly inside the Run window.
I guess GoLands terminal is a fake terminal without real cursor addressability. There may not be a good solution if that is the case.
I’m the author of tcell and I use goland but I confess I always run my test programs in a real terminal rather than in the toy terminal that the IDE provides. This is true whether I use goland, visual studio code, or even the venerable emacs.
By using a new Batch run configuration, you can run a batch file to build the program, then run the program in a new cmd window.
In the run configuration in GoLand, set "Working directory" to the main package directory. Then set the script to a new batch file.
Here is the code in my batch file for my package client
go build
start cmd /C client.exe
Running this configuration will build the package, then run the program in a new external cmd window where the cells display properly.
This solution isn't great, because most of the advantages of the GoLand run configuration system are lost, including debugging, process management (stop / restart), and other build options.
Does anyone have a better solution?
I am a newbie in go and go-swagger. I am following steps in Simple Server tutorial in goswagger.io.
I am using Ubuntu 18.04, swagger v0.25.0 and go 1.15.6.
Following the same steps, there are a few differences of the files generated. For instance, goswagger.io's has find_todos_okbody.go and get_okbody.go in models but mine does not. Why is that so?
Link to screenshot of my generated files vs
Link to screenshot of generated files by swagger.io
Starting the server as written in the tutorial go install ./cmd/todo-list-server/ gives me the following error. Can anyone please help with this?
# my_folder/swagger-todo-list/restapi
restapi/configure_todo_list.go:41:8: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
restapi/configure_todo_list.go:42:6: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
The first step in goswagger.io todo-list is swagger init spec .... Which directory should I run this command in? I ran it in a newly created folder in my home directory. However, from the page, it shows the path to be ~/go/src/github.com/go-swagger/go-swagger/examples/tutorials/todo-list. I am not sure whether I should use go get ..., git clone ... or create those folders. Can someone advise me?
Thanks.
This is likely the documentation lagging behind the version of the code that you are running. As long as it compiles, the specific files the tool generates isn't so crucial.
This is a compilation error. When you do go install foo it will try to build the foo package as an executable and then move that to your GOPATH/bin directory. It seems that the generated code in restapi/configure_todo_list.go isn't correct for the operations code generated.
All you need to run this tutorial yourself is an empty directory and the swagger tool (not its source code). You run the commands from the root of this empty project. In order not to run into GOPATH problems I would initialise a module with go mod init todo-list-example before doing anything else.
Note that while the todo-list example code exists inside the go-swagger source, it's there just for documenting example usage and output.
What I would advice for #2 is to make sure you're using a properly released version of go-swagger, rather than installing from the latest commit (which happens when you just do a go get), as I have found that to be occasionally unstable.
Next, re-generate the entire server, but make sure you also regenerate restapi/configure_todo_list.go by passing --regenerate-configureapi to your swagger generate call. This file isn't always refreshed because you're meant to modify it to configure your app, and if you changed versions of the tool it may be different and incompatible.
If after that you still get the compilation error, it may be worth submitting a bug report at https://github.com/go-swagger/go-swagger/issues.
Thanks #EzequielMuns. The errors in #2 went away after I ran go get - u -f ./... as stated in
...
For this generation to compile you need to have some packages in your GOPATH:
* github.com/go-openapi/runtime
* github.com/jessevdk/go-flags
You can get these now with: go get -u -f ./...
I think it's an error of swagger code generation. You can do as folloing to fix this:
delete file configure_todo_list.go;
regenerate code.
# swagger generate server -A todo-list -f ./swagger.yml
Then, you can run command go install ./cmd/todo-list-server/, it will succeed.
I have created a go script that compiles, starts, checks the status, and ends a web service I created (that is also in go). However, I have come to a road block.
With the compile feature I run the following command:
go install .
Which gives the following error:
./script.go:55: main redeclared in this block
previous declaration at ./hello.go:8
Which makes sense as I have two different files, both with the main func and main package. I also tried moving the script to another folder and then changing the command ran to:
go install {path}
Where {path} is equal to the path I want installed/compiled. Which I then got the following error:
exit status 1: can't load package: package /var/www/test.com/go: import "/var/www/test.com/go": cannot import absolute path
So in conclusion I have thought of only one solution (and I am up to hear others if mine isn't the best approach). My idea is to exclude the script file from compiling with the rest of the files, but I am unsure how to.
I did some research and couldn't find an easy way to do it (such as an --exclude flag with the go install command). Does anybody know how to accomplish what I am trying to achieve?
Thank you.
you could give the hello.go a different package name, that should work. Or i am missing something?
Regards
Tim