tree e00ab3d8b3f9e84b58636ad03358ecdcd7769eda
parent 57ba5051df9b5cc3735711e3fc02497a8cc39d89
author Hana <hyangah@gmail.com> 1619585948 -0400
committer Hyang-Ah Hana Kim <hyangah@gmail.com> 1619626555 +0000

test/integration/goDebug: get goroutines reliably in switch goroutine test

switch goroutine test uses two goroutines. In order to get the goroutine
ids, the test called a threads request and searched 'main.run1' and 'main.run2'
from the goroutines' names. We observed there is no guarantee that the top
most stack contains the function names. It's possible that the goroutine is
running runtime code. For example, this is the threads response we got from
a failed test run in github action CI.

-> server: {"type":"request","seq":10,"command":"threads"}

<- server: {"seq":0,"type":"response","request_seq":10,"success":true,"command":"threads","body":{"threads":[
   {"id":1,"name":"[Go 1] main.main"},
   {"id":2,"name":"[Go 2] runtime.gopark"},
   {"id":3,"name":"[Go 3] runtime.gopark"},
   {"id":4,"name":"[Go 4] runtime.gopark"},
   {"id":17,"name":"[Go 17] runtime.sigtramp (Thread 13304)"},
   {"id":18,"name":"* [Go 18] main.run2 (Thread 13299)"}]}}

The goroutine 17 is running main.run1 but that is not the top most frame.
So, later when using the main.run1 goroutine's id, the test threw an error.

This change makes the test retrieve goroutine id when the breakpoint on
the goroutine is hit - so the main.run1 and main.run2 functions are in
the top of the stack.

Change-Id: I478d0d7e90730a710954d98c278fe2a7b4a7c3a1
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/314589
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Suzy Mueller <suzmue@golang.org>