debug: unable to produce stack trace: "unknown goroutine 1"

[hyangah]

VSCode insiders: 1.46.0-insider
Go Nightly: 2020.6.322
darwin/amd64
go: 1.14.3
delve: 1.4.1

Start debugging (F5) the following program.

package main

import (
	"log"
	"net/http"
)

func main() {
	http.HandleFunc("/test", test)
	log.Fatal(http.ListenAndServe(":8080", nil))
}

func test(w http.ResponseWriter, r *http.Request) {
	w.Write([]byte("test"))
}

with launch.json

{   
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "go",
            "request": "launch",
            "mode": "auto",
            "program": "${fileDirname}",
            "env": {},
            "args": [],
            "stopOnEntry": true,
            "trace":"log",
            "showLog":true,
            "logOutput": "rpc"
        }
    ]
}

attached: debug log

When delve returns no goroutine, the debug adapter inserts a "Dummy" goroutine with id 1. VS Code subsequently issues StackTraceRequest for ID 1, and that results in "unknown goroutine 1" error.

@polinasok

[polinasok]

This is more or less working as intended. There are no goroutines on program entry that delve can report on. But vscode requires that at least 1 thread (and in our case goroutine) is returned. Returning none doesn't work and is against the spec. I discovered this from experience when implementing the DAP version - see our discussion here: go-delve/delve#1914 (comment) and the original discussion here: microsoft/vscode-go#2126 (comment). And if you return a goroutine that doesn't exist, you will understandably get back a stack trace error.

What might make sense is the following:
(1) Suppress the user pop-up since this information is already displayed under CALL STACK anyway.
(2) Have a special case for this error displayed under CALL STACK to turn "Unable to produce stack trace: "unknown goroutine 1"" into "Unable to produce stack trace" or "Unable to produce stack trace: goroutine information is not available".

[polinasok]

Just for comparison, if you use delve front-end with "dlv debug" or similar subcommand, on entry you will also get no goroutine information and no usable stack as well:

$ dlv debug increment.go 
Type 'help' for list of commands.
(dlv) goroutines
[0 goroutines]
(dlv) stack
0  0x0000000008d08000 in ???
   at ?:-1
   error: protocol error E08 during memory read for packet $m8,8
(truncated)
(dlv) b main.main
Breakpoint 1 set at 0x10c4318 for main.main() ./increment.go:16
(dlv) c
> main.main() ./increment.go:16 (hits goroutine(1):1 total:1) (PC: 0x10c4318)
    11:			return (2 * Increment(y/2))
    12:		}
    13:		return y + 1
    14:	}
    15:	
=>  16:	func main() {
    17:		fmt.Printf("%d\n", Increment(3))
    18:	}
(dlv) goroutines
* Goroutine 1 - User: ./increment.go:16 main.main (0x10c4318) (thread 4581587)
  Goroutine 2 - User: /usr/local/go/src/runtime/proc.go:305 runtime.gopark (0x10365fb)
  Goroutine 3 - User: /usr/local/go/src/runtime/proc.go:305 runtime.gopark (0x10365fb)
  Goroutine 17 - User: /usr/local/go/src/runtime/proc.go:305 runtime.gopark (0x10365fb)
  Goroutine 18 - User: /usr/local/go/src/runtime/proc.go:305 runtime.gopark (0x10365fb)
[5 goroutines]
(dlv) stack
0  0x00000000010c4318 in main.main
   at ./increment.go:16
1  0x0000000001036248 in runtime.main
   at /usr/local/go/src/runtime/proc.go:203
2  0x0000000001063ce1 in runtime.goexit
   at /usr/local/go/src/runtime/asm_amd64.s:1373

[hyangah]

Thanks for the investigation. @polinasok
Can you try after setting the breakpoint? (in main or log.Fatal line)?

This popup appears and there is no stack trace even though there should be.
I think we should suppress this popup if we know we gave the dummy goroutine.

[polinasok]

Your pictorial example is for "stop on entry". Could you please be more specific as to where exactly you want me to set a breakpoint to reproduce what you are referring to?

I do agree that a pop-up is unnecessary here. Hence see my earlier suggestion (1).

[hyangah]

[polinasok]

You are not paused at a breakpoint here. The red dot is not highlighted. You are paused on entry before the program and any goroutines started running. The CALL STACK says "paused on entry", not "paused on breakpoint". If you click continue and pause on breakpoint, you should not see this pop-up anymore and the CALL STACK should show you something useful.

[polinasok]

You should have a setting in launch.json configuration "stopOnEntry": true. Set it to false and you will skip this situation all-together.

[hyangah]

Ah I see. TBH I don't know how 'stopOnEntry' got there :-) and I didn't get any stack trace after clicking continue. After upgrading to VS Code, it started to appear. Thanks for the explanation.

I think suppressing the popup is sufficient. I think it's better if we can display something that makes sense more than "unknown goroutine 1" (e.g."no goroutine") but we can live with that.

[polinasok]

I have been working out some complicated logic to special handle the dummy goroutine case, but then it occurred to me: is there any advantage in having a pop-up for the stacktrace errors? The stack traces are not explicitly requested by the user, but are a side effect of other events and already show up on the side under CALL STACK anyway, right? So perhaps it makes sense to suppress the pop-ups for all of "Unable to produce stack trace" situations?

[hyangah]

@polinasok Thanks for the investigation. Let's suppress the pop-up - the necessary information is already under CALL STACK as you pointed out.

[polinasok]

In dlv-dap, stackTrace handler already uses an error response helper that sets showUser to false by default.

[gopherbot]

Change https://golang.org/cl/293530 mentions this issue: src/debugAdapter: disable stackTrace error pop-ups