go: x/exp/shiny: SIGILL: illegal instruction on macOS Catalina with Xcode 11.1 running basic example
What version of Go are you using (go version)?
$ go version go version go1.13.3 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/leighmcculloch/Library/Caches/go-build" GOENV="/Users/leighmcculloch/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/leighmcculloch/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" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/leighmcculloch/go/src/github.com/golang/exp/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 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/cn/mvxdpxj10pxgx6h74_knhyyc0000gn/T/go-build851615509=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
I ran the x/exp/shiny/example/basic example application.
git clone https://github.com/golang/exp
cd exp/
go run -tags=example ./shiny/example/basic
What did you expect to see?
The basic graphical application to display.
What did you see instead?
An invalid instruction panic.
SIGILL: illegal instruction
PC=0x7fff2eda88a1 m=5 sigcode=1
signal arrived during cgo execution
Full Output
% go run -tags=example ./shiny/example/basic
go: downloading golang.org/x/mobile v0.0.0-20190719004257-d2bd2a29d028
go: downloading golang.org/x/image v0.0.0-20190802002840-cff245a6509b
go: extracting golang.org/x/mobile v0.0.0-20190719004257-d2bd2a29d028
go: extracting golang.org/x/image v0.0.0-20190802002840-cff245a6509b
go: finding golang.org/x/image v0.0.0-20190802002840-cff245a6509b
go: finding golang.org/x/mobile v0.0.0-20190719004257-d2bd2a29d028
SIGILL: illegal instruction
PC=0x7fff2eda88a1 m=5 sigcode=1
signal arrived during cgo execution
goroutine 20 [syscall, locked to thread]:
runtime.cgocall(0x40c4170, 0xc00002ef10, 0x0)
/usr/local/go/src/runtime/cgocall.go:128 +0x5b fp=0xc00002eee0 sp=0xc00002eea8 pc=0x400537b
golang.org/x/exp/shiny/driver/gldriver._Cfunc_makeCurrentContext(0x44426c0)
_cgo_gotypes.go:298 +0x41 fp=0xc00002ef10 sp=0xc00002eee0 pc=0x40bf1f1
golang.org/x/exp/shiny/driver/gldriver.drawLoop(0xc0000ae000, 0x1)
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/driver/gldriver/cocoa.go:147 +0x60 fp=0xc00002efd0 sp=0xc00002ef10 pc=0x40c02a0
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1357 +0x1 fp=0xc00002efd8 sp=0xc00002efd0 pc=0x4058971
created by golang.org/x/exp/shiny/driver/gldriver.preparedOpenGL
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/driver/gldriver/cocoa.go:92 +0xe4
goroutine 1 [chan receive, locked to thread]:
golang.org/x/exp/shiny/driver/gldriver.drawgl(0x457b340)
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/driver/gldriver/cocoa.go:134 +0x15e
golang.org/x/exp/shiny/driver/gldriver._cgoexpwrap_db502a3a14da_drawgl(0x457b340)
_cgo_gotypes.go:377 +0x2b
golang.org/x/exp/shiny/driver/gldriver._Cfunc_startDriver()
_cgo_gotypes.go:311 +0x41
golang.org/x/exp/shiny/driver/gldriver.main(0x4116cd8, 0xc000040f50, 0x4007c6f)
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/driver/gldriver/cocoa.go:107 +0x4d
golang.org/x/exp/shiny/driver/gldriver.Main(0x4116cd8)
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/driver/gldriver/gldriver.go:26 +0x2f
golang.org/x/exp/shiny/driver.main(...)
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/driver/driver_darwin.go:15
golang.org/x/exp/shiny/driver.Main(...)
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/driver/driver.go:24
main.main()
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/example/basic/main.go:44 +0x2e
goroutine 19 [chan receive]:
golang.org/x/mobile/gl.(*context).enqueue(0xc0000b0000, 0x57, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/Users/leighmcculloch/go/pkg/mod/golang.org/x/mobile@v0.0.0-20190719004257-d2bd2a29d028/gl/work.go:111 +0xd3
golang.org/x/mobile/gl.(*context).IsProgram(0xc0000b0000, 0xa8b00, 0x68)
/Users/leighmcculloch/go/pkg/mod/golang.org/x/mobile@v0.0.0-20190719004257-d2bd2a29d028/gl/gl.go:1045 +0xcb
golang.org/x/exp/shiny/driver/gldriver.(*screenImpl).NewTexture(0x41e8220, 0x100, 0x100, 0x0, 0x0, 0x0, 0x0)
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/driver/gldriver/screen.go:78 +0x1a0
main.main.func1(0x412e760, 0x41e8220)
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/example/basic/main.go:61 +0x267
golang.org/x/exp/shiny/driver/gldriver.driverStarted.func1()
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/driver/gldriver/cocoa.go:114 +0x40
created by golang.org/x/exp/shiny/driver/gldriver.driverStarted
/Users/leighmcculloch/go/src/github.com/golang/exp/shiny/driver/gldriver/cocoa.go:113 +0x35
rax 0x0
rbx 0xc00002ef10
rcx 0x0
rdx 0x0
rdi 0x0
rsi 0x1f08000c
rbp 0x70000508aef0
rsp 0x70000508aeb0
r8 0x0
r9 0x0
r10 0x0
r11 0x0
r12 0x44426c0
r13 0x0
r14 0x4031440
r15 0x0
rip 0x7fff2eda88a1
rflags 0x10202
cs 0x2b
fs 0x0
gs 0x0
exit status 2
I originally experienced this issue attempting to run gdlv and opened an issue at aarzilli/gdlv#45 but was redirected here by @dmitshur.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 27 (26 by maintainers)
Thank for the extra information. That does make more sense.
The
ud2is from C code compiled by Apple. That is typically generated by C compilers for calls to__builtin_trapor__builtin_unreachable.I agree that this does look like a missing
runtime.LockOSThreadsomewhere.Thank you for the guidance.
I’ve tried
lldband it seems to provide output that is a lot more informative. The crash happens inside AppKit code and this time its source is being included:Instructions before the offending one:
Full disassembly
Notably, it points to ud2 as the instruction that caused EXC_BAD_INSTRUCTION, which makes a lot more sense. I don’t know if delve’s output was wrong or just incomplete.
If the “must be called from the main thread if the context has a view” text is relevant, that gives something for me to investigate in shiny’s
gldriverimplementation.I wonder what led to ud2 instruction being the one to crash the program instead of something else that provides more information to the end user, and if that can be improved. (Is that to do with Apple or Go?)
Possibly related, a SIGILL on Catalina for Filemaker 18: https://community.filemaker.com/en/s/question/0D50H000072r8OmSAI/filemaker-18-advanced-crashes-in-os-catalina-beta-19a526h-when-leaving-layout-mode
Model:
Video Card:
OS:
The give away might be the feature set
GPUFamily2 v1. What feature set does your MacBook Pro have?