(WIP) Delve v2 API debug adapter

[lggomez]

Initial integration to v2 api for #1555. This includes additional debugger options for launch configuration

[lggomez]

@ramya-rao-a PTAL

My second point from this comment still stands, on whether should we preserve the v1 adapter or not

Linux testing so far is going alright. I will continue on mac, although I don't have any windows VMs to test at the moment

[ramya-rao-a]

@lggomez I will finally have some time next week to go over this, thanks for you patience. I have a Windows machine and I can take up the testing on it.

[lggomezml]

I found a breaking change in the behavior that I have to fix: if a breakpoint is defined in a no-code line, the following breakpoint requests fail:

package main

import "fmt"

func main() {
	foo := "hello world"
	fmt.Println(foo)
}

Having a breakpoint on lines 2 or 4 will break breakpoint requests on runtime

[lggomez]

This is the current example I have of the bug:

When I start debugging, I can see the breakpoints activated but with errors on the request:

SetBreakPointsRequest
All cleared
Creating on: /home/razael/go/src/github.com/go-training/helloworld/main.go:4
Creating on: /home/razael/go/src/github.com/go-training/helloworld/main.go:6
Error on CreateBreakpoint: no code at /home/razael/go/src/github.com/go-training/helloworld/main.go:4
{}
2018/05/12 01:49:46 debugger.go:340: created breakpoint: &api.Breakpoint{ID:1, Name:"", Addr:0x49c1af, File:"/home/razael/go/src/github.com/go-training/helloworld/main.go", Line:6, FunctionName:"main.main", Cond:"", Tracepoint:false, Goroutine:false, Stacktrace:0, Variables:[]string(nil), LoadArgs:(*api.LoadConfig)(0xc42002a2d0), LoadLocals:(*api.LoadConfig)(0xc42002a330), HitCount:map[string]uint64{}, TotalHitCount:0x0}`

After I try to set a new breakpoint, all further requests fail:

SetBreakPointsRequest
All cleared
Creating on: /home/razael/go/src/github.com/go-training/helloworld/main.go:4
Creating on: /home/razael/go/src/github.com/go-training/helloworld/main.go:6
Creating on: /home/razael/go/src/github.com/go-training/helloworld/main.go:7
Error on CreateBreakpoint: no code at /home/razael/go/src/github.com/go-training/helloworld/main.go:4
Error on CreateBreakpoint: Breakpoint exists at /home/razael/go/src/github.com/go-training/helloworld/main.go:6 at 49c1af
2018/05/12 01:50:27 debugger.go:340: created breakpoint: &api.Breakpoint{ID:2, Name:"", Addr:0x49c1c4, File:"/home/razael/go/src/github.com/go-training/helloworld/main.go", Line:7, FunctionName:"main.main", Cond:"", Tracepoint:false, Goroutine:false, Stacktrace:0, Variables:[]string(nil), LoadArgs:(*api.LoadConfig)(0xc42044b4a0), LoadLocals:(*api.LoadConfig)(0xc42044b530), HitCount:map[string]uint64{}, TotalHitCount:0x0}
{}

By the looks of it, it seems that the CreateBreakpoint failure is not handled appropiately and the following requests will always fail since the GoDebugSession.breakpoints end up in an invalid state, thus cleanup of failed/invalid breakpoints should be applied on promise rejections for CreateBreakpoint (and maybe ClearBreakpoint, I'm still not sure about that one)

It may also be bad handling of promise rejections from the v2 api on our side. I'm still not well versed on Typescript, so any pointers will be helpful

[ramya-rao-a]

@lggomez 6dfbfec should fix the issue you have described in #1647 (comment)

[ramya-rao-a]

I've tested simple program on Windows. Works great. Other scenarios we should test are

• debugging tests
• debugging tests using code lens
• remote debugging

[ramya-rao-a]

@lggomez I have tested in Windows and below are my findings

• Debugging tests using v1 and v2 via configs in launch.json works
• Debugging tests via codelens gets its configuration from code and doesnt read launch.json file. This makes me wonder if we should move the LoadConfig configuration to normal settings.
• Remote Debugging: Step in/out/over and creating breakpoints work. But the variables dont show any value in debug viewlet when using v2. Can you give this a try? I tested by running a headless dlv server in an external terminal and then creating config in the launch.json file to attach to it

[primalmotion]

I'm running this PR without problem, but I'm still facing this issue #978 (comment)

[ramya-rao-a]

@primalmotion Have you tried remote debugging?

[primalmotion]

@ramya-rao-a nope but I can. do you have a config example?

[primalmotion]

forget it found it. I tried, exact same issue.
I start delve with dlv exec --headless --listen=:2345 --log --api-version 2 prog
set "mode": "remote", in launch.json

it's even worse. I can't ctrl-c my server, vscode gets stuck in debugging mode trying to restart, and I have to reload the window

[lggomez]

@primalmotion

This is the setup I use on the dev host:

    "version": "0.2.0",
    "configurations": [
        {
            "name": "Connect to server",
            "type": "go",
            "request": "launch",
            "mode": "remote",
            "remotePath": "${workspaceRoot}",
            "port": 8181,
            "host": "127.0.0.1",
            "program": "${workspaceRoot}",
            "env": {},
            "args": [],
            "dlvLoadConfig" : {
                "maxVariableRecurse": 1,
                "maxStringLen": 10,
                "maxArrayValues": 10,
                "maxStructFields": -1
            },
            "useApiV1": false
        },

And these are the commands for both v1 and v2:

    dlv debug --headless --log --listen=127.0.0.1:8181
    dlv debug --headless --api-version=2 --log --listen=127.0.0.1:8181

I didn't have time to check the variables on remote yet, but I'll get on it as soon as I can

[primalmotion]

@lggomez I just tried exactly this, same issue (with the addition that I have to kill -9 delve to stop it)

[lggomez]

@ramya-rao-a @primalmotion

I've not been able to repro the issues on v2 remote debug, this is my current state:

Can you share the apicall responses for those that are giving you problems right now?

I change these log calls to logger.error in order to get a more detailed view of the apicall results if needed

[primalmotion]

Sure I’ll give it a try on Monday.

…

-- Antoine Mercadal

On May 19, 2018, at 7:20 PM, Luis GG ***@***.***> wrote: @ramya-rao-a @primalmotion I've not been able to repro the issues on v2 remote debug, this is my current state: Can you share the apicall responses for those that are giving you problems right now? I change (https://github.com/Microsoft/vscode-go/blob/master/src/debugAdapter/goDebug.ts#L160-L166)[these] log calls to error in order to get a more detailed view of the apicall results if needed — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ramya-rao-a]

• The program I am debugging: https://github.com/golang/example/blob/master/hello/hello.go
• Headless server: dlv debug --headless --log --api-version=2 --listen=127.0.0.1:2345
• Debug config in the launch.json file:

{
            "name": "Launch",
            "type": "go",
            "request": "launch",
            "mode": "remote",
            "remotePath": "",
            "port": 2345,
            "host": "127.0.0.1",
            "program": "${fileDirname}",
            "env": {},
            "args": [],
            "showLog": true,
            "useApiV1": false,
            "trace": "verbose"
        }

• Response for the "ScopesRequest" and "VariablesRequest". As you can see the variable s is empty.

- Update the `remote` to `debug` in the launch.json file and the you get the below. As you can see the variable `s` is not empty

[lggomez]

Ok, so I actually hit a diff wit that launch config, the VariablesRequest calls seem to fail on remote

Something interesting about this is that numeric literals seem to work, while everything else fails since they do the calls on demand

[lggomez]

On a side note, the dlv debug output is as verbose as it gets so we'll have to live without it for now. I'd like to see if there are any differences between the debugger state and the actual response received by the adapter on the LocalVariables call, although it might be a bit far-fetched from the actual cause of this regression

I raised an issue about this to see if they welcome the idea

[lggomez]

@ramya-rao-a I fixed the issue, it turns out that the delve loadConfig was not being intialized for remote sessions because that path has en early return. It should work correctly now