GoDebugContinue doesnot work in windows 10

[liwnn]

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

I debug the only file "main.go" in path "E:\GoProjects\src\foo".

The dlv version:
Version: 1.3.0
Build: $Id: 2f59bfc686d60989dcef9de40b480d0a34aa2fa5 $

The commands:
GoDebugStart
GoDebugBreakPoint
GoDebugContinue

What did you expect to happen?

What happened instead

After about 10 more seconds, it disappears as below:

Configuration (MUST fill this out):

vim-go version:

The master branch

vimrc you used to reproduce (use a minimal vimrc with other plugins disabled; do not link to a 2,000 line vimrc):

vimrc

filetype plugin indent on
syntax on
let g:go_fmt_command = "goimports"

let g:go_gocode_unimported_packages = 1

let g:go_list_type = 'quickfix'

let g:go_list_height = 10

let g:go_highlight_types = 1

let g:go_highlight_fields = 1

let g:go_highlight_functions = 1

let g:go_highlight_function_calls = 1

let g:go_highlight_operators = 1

let g:go_highlight_variable_declarations = 1

let g:go_highlight_variable_assignments = 1

Vim version (first three lines from :version):

Go version (go version):

go version go1.12.7 windows/amd64

Go environment

go env Output:

set GOARCH=amd64
set GOBIN=E:\GoProjects\bin
set GOCACHE=C:\Users\wining\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=E:\GoProjects\;
set GOPROXY=
set GORACE=
set GOROOT=D:\Go
set GOTMPDIR=
set GOTOOLDIR=D:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\wining\AppData\Local\Temp\go-build108456678=/tmp/go-build -gno-record-gcc-switches

[bhcleek]

There's an error in the delve output there. Perhaps you're not using the version of delve that you think you are. Like last time, can you start vim with vim -c 'let g:go_debug=['shell-commands'], duplicate y our problem, and then run the delve command that's output in the directory of the file you're debugging? You can safely elide the ---headless, --listen, and 127.0.0.1:8181 options.

Note that the command that's output by vim-go will be in an array of quoted strings. Of course, you'll want to convert that to the proper commandline form by removing the square brackets and quotes where appropriate.

[liwnn]

It seems to work well with dlv command.

[bhcleek]

Do you see the same problem with :GoDebugContinue even when debugging a very simple application? e.g.:

package main

func main() {
    println("Hello, vim-go debugger")
}

[liwnn]

Yes. The example has the same problem.

[bhcleek]

What's the output in the GODEBUG_OUTPUT window when debugging the simple example?

[liwnn]

[liwnn]

It seems to work well. But when the first time run GoDebugContinue, it will stop for about 10 seconds.

[liwnn]

Is this gif helpful?

[bhcleek]

The gif doesn't seem to show much else other than what we've already talked about. 🤔

[liwnn]

This issue has not been fixed!
I add some log and find that the function "update_goroutines" and "update_variables" causes this.
It seems that the call "s:call_jsonrpc('RPCServer.State')" and “s:call_jsonrpc('RPCServer.ListGoroutines')” in function "update_goroutines" are timeout.
Can i add some logs to help you？

[liwnn]

I add echo in function "s:call_jsonrpc" in file "autoload\go\debug.vim".

function! s:call_jsonrpc(method, ...) abort
...
      call ch_sendraw(l:ch, req_json)
      "debug
      if go#util#HasDebug('debugger-commands')
        call go#util#EchoInfo('before ch_readraw ' . l:req_json)
      endif
      let l:resp_raw = ch_readraw(l:ch)
      "debug
      if go#util#HasDebug('debugger-commands')
        call go#util#EchoInfo('after ch_readraw ' . l:resp_json)
      endif
      let resp_json = json_decode(l:resp_raw)
...

endfunction

The three requests in Red box were timeout and had empty replies in windows.

[bhcleek]

@wining Can you please open a new issue with this information?

Also, how do you know they were timeouts?

[bhcleek]

@wining another piece of information to include in the new issue; are you still seeing the original reported behavior where you saw an error that reads, Undefined variable?

[liwnn]

@wining Can you please open a new issue with this information?

Also, how do you know they were timeouts?

Because every call of "ch_readraw(l:ch)" will spend 20 seconds.

[liwnn]

@wining another piece of information to include in the new issue; are you still seeing the original reported behavior where you saw an error that reads, Undefined variable?

There is no error reportes. I will create a new issue.