Vim-go: cannot enter commands while waiting for the debugger to yield

[MatthewMarkgraaff]

Firstly, thank you so much for all your effort on this package. I'm having such a great time hacking away on go inside vim now thanks to this plugin! Just having some developer experience issues when working with the built in delve / debugger support.

What did you do? (required: The issue will be closed when not provided)

On Occasion GoDebugContinue and GoDebugStop cause vim instance to freeze. Can't execute further commands or navigate the editor.

What did you expect to happen?

GoDebugContinue should continue to the next breakpoint, if no further breakpoints are set, control should be given back to the developer to navigate vim and set more breakpoints or to just navigate normally.

What happened instead?

Vim hangs sometimes indefinitely and requires a force quit, other times for a long period of time before vim becomes responsive again

Sometimes setting a breakpoint throws: vim-go: Vim(let):E121: Undefined variable: result

General experience is laggy and the debugging experience differs on each use.

Configuration (MUST fill this out):

vim-go version:

vimrc you used to reproduce:

vimrc

set rtp+=~/.vim/bundle/Vundle.vim

call vundle#begin()

Plugin 'VundleVim/Vundle.vim'

Plugin 'fatih/vim-go'

call vundle#end()

Vim version (first three lines from :version):

VIM - Vi IMproved 8.1 (2018 May 18, compiled Jun 26 2019 04:37:19)
macOS version
Included patches: 1-1600

Go version (go version):

go1.13.4

Go environment

go env Output:

GO111MODULE=""

GOARCH="amd64"

GOBIN=""

GOCACHE="/Users/Matt/Library/Caches/go-build"

GOENV="/Users/Matt/Library/Application Support/go/env"

GOEXE=""

GOFLAGS=""

GOHOSTARCH="amd64"

GOHOSTOS="darwin"

GONOPROXY=""

GONOSUMDB=""

GOOS="darwin"

GOPATH="/Users/Matt/go"

GOPRIVATE=""

GOPROXY="https://proxy.golang.org,direct"

GOROOT="/usr/local/go"

GOSUMDB="sum.golang.org"

GOTMPDIR=""

GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"

GCCGO="gccgo"

AR="ar"

CC="clang"

CXX="clang++"

CGO_ENABLED="1"

GOMOD="/Users/Matt/development/tmp/demo/go.mod"

CGO_CFLAGS="-g -O2"

CGO_CPPFLAGS=""

CGO_CXXFLAGS="-g -O2"

CGO_FFLAGS="-g -O2"

CGO_LDFLAGS="-g -O2"

PKG_CONFIG="pkg-config"

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/2l/6ghqhzmj5pq14n2yq8q1b_qm0000gn/T/go-build090696297=/tmp/go-build -gno-record-gcc-switches -fno-common"

gopls version

gopls version Output:

golang.org/x/tools/gopls v0.3.2

dlv version

Delve Debugger
Version: 1.4.0
Build: $Id: 67422e6f7148fa1efa0eac1423ab5594b223d93b

simple code example

code example Example:

package main

import (

    "fmt"

    "net/http"

)

func main() {

    http.HandleFunc("/", HelloServer)

    http.ListenAndServe(":8080", nil)

}

func HelloServer(w http.ResponseWriter, r *http.Request) {

    fmt.Println("Hello world!")

    fmt.Fprintf(w, "Hello, %s!", r.URL.Path[1:])

}

I set breakpoints on the HelloServer handler and curl localhost:8080

I can try take a video of the experience I'm having, as it's quite difficult to articulate in writing.

[bhcleek]

GoDebugContinue should continue to the next breakpoint, if no further breakpoints are set, control should be given back to the developer to navigate vim and set more breakpoints or to just navigate normally.

If there are no breakpoints set, then the application is running and Vim is waiting for the debugger to break. That's probably the root cause of what you're seeing.

This can be improved, though; I'll see what I can do.

Sometimes setting a breakpoint throws: vim-go: Vim(let):E121: Undefined variable: result

🤔 Can you duplicate this relatively reliably? Having the requests and responses to and from delve would help me get to a root cause. If you'll let g:go_debug=['debugger-commands'] then you can echo string(g:go_debug_commands) to see them. Also, the content of the __GODEBUG_OUTPUT__ window after the error would be hugely helpful.

[MatthewMarkgraaff]

Sure I'll try to find steps that lead to a consistently reproducible case

[MatthewMarkgraaff]

Ok so here are the steps taken to get to reproduce Undefined variable: result (using the code example I posted in the first post):

1. :GoDebugBreakpoint on the fmt.Println("Hello world!")
2. :GoDebugStart
3. :GoDebugContinue wait for vim-go to yield control back to user
4. :GoDebugBreakpoint on the fmt.Fprintf(w, "Hello, %s!", r.URL.Path[1:]) line should throw the error

output of debugger-commands is:

After :GoDebugContinue: vim-go: sending to dlv RPCServer.Command
When creating second breakpoint: vim-go: sending to dlv RPCServer.CreateBreakpoint

Output:

ERR: 2020-06-11T22:11:28+02:00 debug layer=rpc API server pid = 84267
ERR: 2020-06-11T22:11:28+02:00 info layer=debugger launching process with args: [/var/folders/2l/6ghqhzmj5pq14n2yq8q1b_qm0000gn/T/vYUNR5D/1]
ERR: 2020-06-11T22:11:28+02:00 debug layer=rpc <- RPCServer.CreateBreakpoint(rpc2.CreateBreakpointIn{"Breakpoint":{"id":0,"name":"","addr":0,"addrs":null,"file":"/Users/Matt/development/tmp/demo/main.go","line":14,"Cond":"","continue":
ERR: 2020-06-11T22:11:28+02:00 info layer=debugger created breakpoint: &api.Breakpoint{ID:1, Name:"", Addr:0x1356f4f, Addrs:[]uint64{0x1356f4f}, File:"/Users/Matt/development/tmp/demo/main.go", Line:14, FunctionName:"main.HelloServer",
ERR: 2020-06-11T22:11:28+02:00 debug layer=rpc -> *rpc2.CreateBreakpointOut{"Breakpoint":{"id":1,"name":"","addr":20279119,"addrs":[20279119],"file":"/Users/Matt/development/tmp/demo/main.go","line":14,"functionName":"main.HelloServer"
ERR: 2020-06-11T22:11:56+02:00 debug layer=rpc (async 2) <- RPCServer.Command(api.DebuggerCommand{"name":"continue","ReturnInfoLoadConfig":null})
ERR: 2020-06-11T22:11:56+02:00 debug layer=debugger continuing
ERR: 2020-06-11T22:12:22+02:00 debug layer=rpc <- RPCServer.CreateBreakpoint(rpc2.CreateBreakpointIn{"Breakpoint":{"id":0,"name":"","addr":0,"addrs":null,"file":"/Users/Matt/development/tmp/demo/main.go","line":15,"Cond":"","continue":false,"traceReturn":false,"goroutine":false,"stacktrace":0,"LoadArgs":null,"LoadLocals":null,"hitCount":null,"totalHitCount":0}})

[bhcleek]

Are you sending an http request to your http server after running :GoDebugContinue? If not, then I don't see how control would yield back to the user in order to be able to run :GoDebugBreakpoint after :GoDebugContinue. 🤔

[bhcleek]

Ah, it returns control after a timeout reading from the socket. Unfortunately, though, I don't see the error you're encountering, though there was recently some changes to the debugger that might affect this. What version of vim-go are you using?

[MatthewMarkgraaff]

Whoops forgot to fill in vim-go version in the original issue.

I'm on commit 26c0029 not sure how to check the plugin version.

[bhcleek]

That commit was before a recent fix that resolved the vim-go: Vim(let):E121: Undefined variable: result error that you're seeing. Can you update to latest master?

After updating, you'll still see your Vim "hang". That's because it's waiting on delve to hit a breakpoint. It will wait up to 20 seconds.

Once we confirm that your vim-go: Vim(let):E121: Undefined variable: result is resolved, I'll still leave this issue open, as I'm going to use it as an reference for improving the UX when vim-go is waiting on delve responses.

[MatthewMarkgraaff]

Updating to the latest master resolves the vim-go: Vim(let):E121: Undefined variable: result issue, thanks @bhcleek :)

[MatthewMarkgraaff]

Having a much better experience using the vim-go debugger. Let me know what else I can do to help once you've implemented some of the UX changes.

[bhcleek]

@MatthewMarkgraaff do you want to give #2932 a try?

[MatthewMarkgraaff]

So vim is blocking after GoDebugContinue (while my webserver is awaiting requests)

If I had setup a breakpoint prior to starting the debugger session and hit the breakpoint, vim is interactive again and I'm able to set more breakpoints etc. If I had not setup any breakpoints prior to starting the debugging session, I am not able to during the debug session. I have to stop the debugger, set a breakpoint then start it back up.

I am able to GoDebugStart, then GoDebugContinue on a line I would like to break on. Vim hangs, but when I send the request, it hits the GoDebugContinue line and vim becomes responsive. If I originally ran GoDebugContinue on an arbitrary line (that won't get hit during that request processing), the server responds to the request but vim remains blocked.

Hope I'm explaining this clearly enough.

[bhcleek]

Are you seeing that in #2932 or on master?

[bhcleek]

@MatthewMarkgraaff should I go ahead and merge #2932 or do you think there are problems with it? Any guidance you can provide would be helpful, especially in the form of a simple application and instructions to demonstrate the problems you see with it.

[MatthewMarkgraaff]

Apologies for the delay in response.
I'm on #2932, yes. I'd say you can go ahead and merge. It's feeling good now 💯

[MatthewMarkgraaff]

The only remaining comment is that I can't run GoDebugStop while the server is waiting for requests after GoDebugContinue. I have to kill the process outside of vim or hit another breakpoint to make vim responsive again. Nothing major, just takes some getting used to. If this is something you want to look into I can provide a short example, steps to reproduce etc.

[bhcleek]

Thanks @MatthewMarkgraaff . I'll plan to address the :GoDebugStop issue separately. I think I've basically already solved that in a local branch that I plan to put up after #2932 is merged.