What version of Go are you using (go version)?
go version go1.16.6 darwin/amd64
Does this issue reproduce with the latest release?
No. Tried with both gotip & go1.17rc1.
I guess it means the bug got fixed, but submitting this issue just in case.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/polina/Library/Caches/go-build"
GOENV="/Users/polina/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/polina/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/polina/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.6"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/polina/delve/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/dn/8hszkj9x21n__1gr_p8qgjgr0007jz/T/go-build3263889025=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
This is a result of an issue file against delve at go-delve/delve#2593.
package main
import "fmt"
func issue2593(z interface{}) error {
switch t := z.(type) {
case string:
if err := issue2593_call(); err != nil {
// Will go here.
return err
}
default:
fmt.Print(t)
}
// Then here
return nil
}
func issue2593_call() error {
return nil
}
func main() {
err := issue2593("test")
// Will print <nil>
fmt.Print(err)
}
Dlv showed odd behavior where a breakpoint inside of the if-statement was unexpectedly hit.
What did you expect to see?
Expected not to enter the if-statement during debugging.
What did you see instead?
6:
7: switch t := z.(type) {
8: case string:
9: if err := issue2593_call(); err != nil {
10: // Will go here.
=> 11: return err
12: }
13: default:
14: fmt.Print(t)
15: }
16:
(dlv) p err
(unreadable invalid interface type: key not found)
A snapshot of what get we from disassemble. 2nd mov after the call should not have a different line number from the rest of the call-related lines, should it?
issue.go:8 0x10cbd11 488d0528b40000 lea rax, ptr [rip+0xb428]
issue.go:8 0x10cbd18 4839442470 cmp qword ptr [rsp+0x70], rax
issue.go:8 0x10cbd1d 7406 jz 0x10cbd25
issue.go:8 0x10cbd1f 90 nop
issue.go:8 0x10cbd20 e917010000 jmp 0x10cbe3c
issue.go:8 0x10cbd25 b801000000 mov eax, 0x1
issue.go:8 0x10cbd2a eb00 jmp 0x10cbd2c
issue.go:8 0x10cbd2c 88442433 mov byte ptr [rsp+0x33], al
issue.go:8 0x10cbd30 84c0 test al, al
issue.go:8 0x10cbd32 7502 jnz 0x10cbd36
issue.go:8 0x10cbd34 eb76 jmp 0x10cbdac
issue.go:8 0x10cbd36 eb00 jmp 0x10cbd38
issue.go:8 0x10cbd38 488b442478 mov rax, qword ptr [rsp+0x78]
issue.go:8 0x10cbd3d 488b08 mov rcx, qword ptr [rax]
issue.go:8 0x10cbd40 488b4008 mov rax, qword ptr [rax+0x8]
issue.go:8 0x10cbd44 48894c2450 mov qword ptr [rsp+0x50], rcx
issue.go:8 0x10cbd49 4889442458 mov qword ptr [rsp+0x58], rax
issue.go:9 0x10cbd4e e80d010000 call $main.issue2593_call
issue.go:9 0x10cbd53 488b442408 mov rax, qword ptr [rsp+0x8]
=> issue.go:11 0x10cbd58* 488b0c24 mov rcx, qword ptr [rsp]
issue.go:9 0x10cbd5c 48833c2400 cmp qword ptr [rsp], 0x0
issue.go:9 0x10cbd61 48894c2460 mov qword ptr [rsp+0x60], rcx
issue.go:9 0x10cbd66 4889442468 mov qword ptr [rsp+0x68], rax
issue.go:9 0x10cbd6b 7502 jnz 0x10cbd6f
issue.go:9 0x10cbd6d eb20 jmp 0x10cbd8f
issue.go:11 0x10cbd6f 48898c24c8000000 mov qword ptr [rsp+0xc8], rcx
issue.go:11 0x10cbd77 48898424d0000000 mov qword ptr [rsp+0xd0], rax
issue.go:11 0x10cbd7f 488bac24a8000000 mov rbp, qword ptr [rsp+0xa8]
issue.go:11 0x10cbd87 4881c4b0000000 add rsp, 0xb0
issue.go:11 0x10cbd8e c3 ret
issue.go:7 0x10cbd8f eb00 jmp 0x10cbd91
With @heschi's help, used GOSSAFUNC=issue2593 go build -gcflags=all="-N -l" issue.go to get ssa.html, which shows same oddly numbered mov:

ssa.html.zip
@dr2chase @randall77
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
No. Tried with both
gotip&go1.17rc1.I guess it means the bug got fixed, but submitting this issue just in case.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
This is a result of an issue file against delve at go-delve/delve#2593.
Dlv showed odd behavior where a breakpoint inside of the if-statement was unexpectedly hit.
What did you expect to see?
Expected not to enter the if-statement during debugging.
What did you see instead?
A snapshot of what get we from
disassemble. 2ndmovafter the call should not have a different line number from the rest of the call-related lines, should it?With @heschi's help, used

GOSSAFUNC=issue2593 go build -gcflags=all="-N -l" issue.goto get ssa.html, which shows same oddly numberedmov:ssa.html.zip
@dr2chase @randall77