debug: stepping fails with 'next while nexting' error

[ramya-rao-a]

From microsoft/vscode-go#2563 by @aarzilli:

1. Debug https://github.com/aarzilli/delve_client_testing/blob/master/05nextbp/main.go
2. set a breakpoint on main.go:23
3. continue once
4. set a breakpoint on main.go:12
5. repeatedly hit next

pretty soon you will encounter the 'next while nexting' error.

For prior discussion on this, please see microsoft/vscode-go#2563

[jkassis]

thumbs up for this. happens all the time and kills a complex debug session.

[jkassis]

also wondering about the status of performance improvements for golang delve debug nexting. still quite slow and not clear what parameters to tweak for improvement. current config is...

  "go.delveConfig": {
    "dlvLoadConfig": {
      "followPointers": true,
      "maxVariableRecurse": 3,
      "maxStringLen": 100,
      "maxArrayValues": 25,
      "maxStructFields": 50
    },
    "apiVersion": 2,
    "showGlobalVariables": false
  },

[polinasok]

It took me a minute to make sense of the original instructions because they appear to assume that the program stops on entry, which is not the default behavior. Everything works if the breakpoint at line 12 is set when stopped at line 23.

Relevant logging:

From client: next({"threadId":1}) <========== next on the current goroutine (1)
NextRequest
To client: {"seq":0,"type":"response","request_seq":15,"command":"next","success":true}
NextResponse
2020-10-20T14:49:02-07:00 debug layer=rpc (async 26) <- RPCServer.Command(api.DebuggerCommand{"name":"next","ReturnInfoLoadConfig":null})
2020-10-20T14:49:02-07:00 debug layer=debugger nexting. <=========== default to current goroutine (1)
2020-10-20T14:49:02-07:00 debug layer=rpc (async 26) -> rpc2.CommandOut{"State":{
      "Running":false,
      "Recording":false,
      "currentThread":{
         "id":4046538,
         "pc":17575364,
         "file":"/Users/polina/go/src/foo/foo.go",
         "line":12,
         "function":{...},
         "goroutineID":31,
         "breakPoint":{ <======================== stopped at a breakpoint in goroutine 31
            "id":2,
            "file":"/Users/polina/go/src/foo/foo.go",
            "line":12,
            "functionName":"main.coroutine",
            "Cond":"",
            "continue":false,
            "traceReturn":false,
            "goroutine":false,
            "stacktrace":0,
            "LoadArgs":{...},
            "LoadLocals":{...},
            "hitCount":{...},
            "totalHitCount":2
         },
         "breakPointInfo":{"arguments":[...], "locals":[...]},
         "ReturnValues":null
      },
      "currentGoroutine":{"id":31, ....},
      "Threads":[...],
      "NextInProgress":true, <=================== while in the middle of next for goroutine 1
      "exited":false,
      "exitStatus":0,
      "When":""
}}  error: ""
next state {"Running":false,...}
2020-10-20T14:49:02-07:00 debug layer=rpc <- RPCServer.ListGoroutines(rpc2.ListGoroutinesIn{"Start":0,"Count":1})
2020-10-20T14:49:02-07:00 debug layer=rpc -> *rpc2.ListGoroutinesOut{"Goroutines":[{"id":1,"currentLoc":{"pc":17539888,"file":"/usr/local/go/src/fmt/format.go","line":357,"function":{"name":"fmt.(*fmt).fmtS","value":17539888,"type":0,"goType":0,"optimized":false}},"userCurrentLoc":{"pc":17539888,"file":"/usr/local/go/src/fmt/format.go","line":357,"function":{"name":"fmt.(*fmt).fmtS","value":17539888,"type":0,"goType":0,"optimized":false}},"goStatementLoc":{"pc":17178374,"file":"/usr/local/go/src/runtime/asm_amd64.s","line":220,"function":{"name":"runtime.rt0_go","value":17178064,"type":0,"goType":0,"optimized":true}},"startLoc":{"pc":16998528,"file":"/usr/local/go/src/runtime/proc.go","line":113,"function":{"name":"runtime.main","value":16998528,"type":0,"goType":0,"optimized":true}},"threadID":4046325,"unreadable":""}],"Nextg":1} error: ""
To client: {"seq":0,"type":"event","event":"stopped","body":{"reason":"step","threadId":31,"allThreadsStopped":true}}
StoppedEvent("step") <================== report stopped on step in 31, assuming next on 1 finished
...... omitting details of status waterfall: threads + stackTrace + scopes + variables
From client: next({"threadId":31}) <============ next on current goroutine (31)
NextRequest
To client: {"seq":0,"type":"response","request_seq":21,"command":"next","success":true}
NextResponse
2020-10-20T14:49:07-07:00 debug layer=rpc (async 33) <- RPCServer.Command(api.DebuggerCommand{"name":"next","ReturnInfoLoadConfig":null})
2020-10-20T14:49:07-07:00 debug layer=debugger nexting
2020-10-20T14:49:07-07:00 debug layer=rpc (async 33) -> <nil>null error: "next while nexting"
Failed to next - next while nexting

[polinasok]

@jkassis Please file an new issue for next performance improvements that are not related to the "next while nexting" error. Thank you.

[polinasok]

@jkassis

thumbs up for this. happens all the time and kills a complex debug session.

The "next while nexting" error is something you can recover from. Continue generally lets you finish the next operation.

@jdowning100 @Basez @ventsislav-georgiev  @lggomez
What would you like the behavior to be when a next on one goroutine is interrupted by breakpoint on another goroutine?

1. Skip and log the breakpoint and finish next on the original goroutine
2. Stop at breakpoint and print an explicit explanation that next is still in progress and to use Continue to finish it
3. Stop at breakpoint and cancel next automatically
4. Stop at breakpoint and make another next cancel the first one and complete relative to the breakpoint
5. Stop at breakpoint and make another next finish the original next on another goroutine
6. Something else

[lggomez]

In my view this is undefined behavior because it would require an underlying execution model stating whether to in this scenario in order to handling it gracefully (like nested interrupts), so my guess is that delve neither wants to make such assumptions (or take that complexity in the backend) and it fails instead (rightfully so)

1 is more simple for the backend to implement but I prefer 2 on the user-level interaction, as the developer will be aware of what's happening

[polinasok]

@lggomez Actually, we are currently trying to implement 1) in go-delve/delve#2530, and it is getting tricky due to concurrency issues. So it got me wondering that was even something that users actually want. At leasts one user does not seem to (go-delve/delve/issues/2317).

[lggomez]

Well yeah, the concurrent breakpoints are a nuance that I underestimated now that I'm seeing the PR. Having the choice from the terminal as aarzilli says here go-delve/delve#2317 (comment) could be an option but not one I see easy to implement or even feasible from the VS Code UI so in this case it'd be preferable to just stop and go with one of the 2-4 variants.

(assuming that concurrency is handled) 3 is more disruptive without notice but easier to implement, although 2 would be more informative to the user but more complex to implement, as it requires a modal and an additional continue request with the next code position

4 and 5 may feel more 'okayish' but are opinionated flows and we may fall again into an issue like go-delve/delve#2530, so I'm between 2 and 3 for now, given what you've just explained

[suzmue]

Option 2 has been implemented in dlv dap

2. Stop at breakpoint and print an explicit explanation that next is still in progress and to use Continue to finish it

An explanation of the behavior can be found in the documentation:

Why does my debug session have an invalid command error when I try to step?

When stepping through a program on a particular goroutine, the debugger will make sure that the step is completed, even when interrupted by events on a different goroutine. If a breakpoint is hit on a different goroutine, the debug adapter will stop the program execution to allow you to inspect the state, even though the step request is still active.

If you attempt to make another step request you will get an invalid command error.

Use Continue to resume program execution.

If you do not want the step request to be interrupted, you can disable all breakpoints from VS Code from the context menu in the Breakpoints view.