Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/exp/shiny: SIGILL: illegal instruction on macOS Catalina with Xcode 11.1 running basic example #35177

Closed
leighmcculloch opened this issue Oct 26, 2019 · 27 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-Darwin
Milestone

Comments

@leighmcculloch
Copy link
Contributor

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.

@leighmcculloch
Copy link
Contributor Author

The above full output is using the gldriver because the metal tag was not provided.

If I use the metal tag like in the following command, the basic example runs, but it displays a blank black canvas in a window. There's a lot of mouse event output that follows.

% go run -tags='metal,example' ./shiny/example/basic    
# github.com/go-gl/glfw/v3.2/glfw
In file included from ../../../../pkg/mod/github.com/go-gl/glfw@v0.0.0-20190409004039-e6da0acd62b1/v3.2/glfw/c_glfw_darwin.go:8:
../../../../pkg/mod/github.com/go-gl/glfw@v0.0.0-20190409004039-e6da0acd62b1/v3.2/glfw/glfw/src/cocoa_window.m:989:9: warning: multiple methods named 'center' found [-Wobjc-multiple-method-names]
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSCollectionViewCompositionalLayout.h:601:19: note: using
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:312:1: note: also found
got lifecycle.Event{From:StageDead, To:StageFocused, DrawContext:<nil>}
got size.Event{WidthPx:1024, HeightPx:768, WidthPt:0, HeightPt:0, PixelsPerPt:0, Orientation:0}
got paint.Event{External:true}
got mouse.Event{X:-115.9375, Y:347.60156, Button:0, Modifiers:0x0, Direction:0x0}
got mouse.Event{X:-114.80469, Y:347.60156, Button:0, Modifiers:0x0, Direction:0x0}
got mouse.Event{X:-112.92969, Y:348.85156, Button:0, Modifiers:0x0, Direction:0x0}
got mouse.Event{X:-111.78906, Y:349.9922, Button:0, Modifiers:0x0, Direction:0x0}
got mouse.Event{X:-109.91406, Y:350.6172, Button:0, Modifiers:0x0, Direction:0x0}
got mouse.Event{X:-108.77344, Y:351.7578, Button:0, Modifiers:0x0, Direction:0x0}
...

Screen Shot 2019-10-25 at 9 04 49 PM

@dmitshur
Copy link
Contributor

I don’t think I’m able to reproduce this on my MacBook Pro, unfortunately.

What is the exact version/build of macOS you’re testing with?

What hardware is it? What video card or video cards?

@dmitshur dmitshur added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Darwin labels Oct 26, 2019
@leighmcculloch
Copy link
Contributor Author

Model:

Model Name: MacBook (Retina, 12-inch, 2017)
Model Identifier: MacBook10,1

Video Card:

Chipset Model: Intel HD Graphics 615
Type: GPU
Bus: Built-In
VRAM (Dynamic, Max): 1536 MB
Vendor: Intel
Device ID: 0x591e
Revision ID: 0x0002
Metal: Supported, feature set macOS GPUFamily2 v1

OS:

macOS Catalina
Version 10.15 (19A583)

The give away might be the feature set GPUFamily2 v1. What feature set does your MacBook Pro have?

@dmitshur
Copy link
Contributor

dmitshur commented Oct 26, 2019

The 2017 MacBook should work fine. The macOS GPUFamily2 v1 feature set is the highest feature set that currently exists, see here for reference.


For comparison, my 2015 MacBook Pro has these feature sets:

$ go run dmitri.shuralyov.com/gpu/mtl/cmd/mtlinfo
preferred system default Metal device: AMD Radeon R9 M370X

AMD Radeon R9 M370X:
	• low-power: no
	• removable: no
	• configured as headless: no
	• registry ID: 4294968594

	Feature Sets:
	• macOS GPU family 1, version 1: ✅ supported
	• macOS GPU family 1, version 2: ✅ supported
	• macOS read-write texture, tier 2: ✅ supported
	• macOS GPU family 1, version 3: ✅ supported
	• macOS GPU family 1, version 4: ✅ supported
	• macOS GPU family 2, version 1: ✅ supported

Intel Iris Pro Graphics:
	• low-power: yes
	• removable: no
	• configured as headless: no
	• registry ID: 4294968434

	Feature Sets:
	• macOS GPU family 1, version 1: ✅ supported
	• macOS GPU family 1, version 2: ✅ supported
	• macOS read-write texture, tier 2: ❌ unsupported
	• macOS GPU family 1, version 3: ✅ supported
	• macOS GPU family 1, version 4: ✅ supported
	• macOS GPU family 2, version 1: ❌ unsupported

@leighmcculloch Can you please share Xcode and clang versions? You can use xcodebuild -version and gcc --version.

@leighmcculloch Also, do you know or remember if this worked before you installed macOS Catalina on your MB?

@leighmcculloch
Copy link
Contributor Author

% xcodebuild -version
Xcode 11.1
Build version 11A1027
% gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

@leighmcculloch
Copy link
Contributor Author

do you know or remember if this worked before you installed macOS Catalina on your MB?

Unfortunately I only started experimenting with these things after upgrading to Catalina.

@leighmcculloch
Copy link
Contributor Author

leighmcculloch commented Oct 26, 2019

I just got my hand on another mac that is seeing the same issue. These are its specs. It's different hardware, different OS version, but same year and same featureset.

Model Name: iMac (Retina 5K, 27-inch, 2017)
Model Identifier: iMac18,3
mac OS Catalina
Version 10.15 (19A602)
Chipset Model: Radeon Pro 580
Type: GPU
Bus: PCIe
PCIe Lane Width: x16
VRAM (Total): 8 GB
Vendor: AMD (0x1002)
Device ID: 0x67df
Revision ID: 0x00c0
ROM Revision: 113-D000AA-931
VBIOS Version: 113-D0001A1X-025
EFI Driver Version: 01.00.931
Metal: Supported, feature set macOS GPUFamily2 v1
% xcodebuild -version
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
% gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Running with opengl the same as above:

% go run -tags=example ./shiny/example/basic
SIGILL: illegal instruction
PC=0x7fff34bb28a1 m=3 sigcode=1
signal arrived during cgo execution
Full Output
SIGILL: illegal instruction
PC=0x7fff34bb28a1 m=3 sigcode=1
signal arrived during cgo execution

goroutine 5 [syscall, locked to thread]:
runtime.cgocall(0x40c4270, 0xc000040710, 0x0)
	/usr/local/go/src/runtime/cgocall.go:128 +0x5b fp=0xc0000406e0 sp=0xc0000406a8 pc=0x400547b
golang.org/x/exp/shiny/driver/gldriver._Cfunc_makeCurrentContext(0x6b055b0)
	_cgo_gotypes.go:298 +0x41 fp=0xc000040710 sp=0xc0000406e0 pc=0x40bf2f1
golang.org/x/exp/shiny/driver/gldriver.drawLoop(0xc0000b2000, 0x1)
	/Users/leighmcculloch/go/src/exp/shiny/driver/gldriver/cocoa.go:147 +0x60 fp=0xc0000407d0 sp=0xc000040710 pc=0x40c03a0
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1357 +0x1 fp=0xc0000407d8 sp=0xc0000407d0 pc=0x4058a71
created by golang.org/x/exp/shiny/driver/gldriver.preparedOpenGL
	/Users/leighmcculloch/go/src/exp/shiny/driver/gldriver/cocoa.go:92 +0xe4

goroutine 1 [chan receive, locked to thread]:
golang.org/x/exp/shiny/driver/gldriver.drawgl(0x45644d0)
	/Users/leighmcculloch/go/src/exp/shiny/driver/gldriver/cocoa.go:134 +0x15e
golang.org/x/exp/shiny/driver/gldriver._cgoexpwrap_db502a3a14da_drawgl(0x45644d0)
	_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(0x4116dd8, 0xc000052f50, 0x4007d6f)
	/Users/leighmcculloch/go/src/exp/shiny/driver/gldriver/cocoa.go:107 +0x4d
golang.org/x/exp/shiny/driver/gldriver.Main(0x4116dd8)
	/Users/leighmcculloch/go/src/exp/shiny/driver/gldriver/gldriver.go:26 +0x2f
golang.org/x/exp/shiny/driver.main(...)
	/Users/leighmcculloch/go/src/exp/shiny/driver/driver_darwin.go:15
golang.org/x/exp/shiny/driver.Main(...)
	/Users/leighmcculloch/go/src/exp/shiny/driver/driver.go:24
main.main()
	/Users/leighmcculloch/go/src/exp/shiny/example/basic/main.go:44 +0x2e

goroutine 19 [chan receive]:
golang.org/x/mobile/gl.(*context).enqueue(0xc0000b4000, 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(0xc0000b4000, 0x57b00, 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/exp/shiny/driver/gldriver/screen.go:78 +0x1a0
main.main.func1(0x412e860, 0x41e8220)
	/Users/leighmcculloch/go/src/exp/shiny/example/basic/main.go:61 +0x267
golang.org/x/exp/shiny/driver/gldriver.driverStarted.func1()
	/Users/leighmcculloch/go/src/exp/shiny/driver/gldriver/cocoa.go:114 +0x40
created by golang.org/x/exp/shiny/driver/gldriver.driverStarted
	/Users/leighmcculloch/go/src/exp/shiny/driver/gldriver/cocoa.go:113 +0x35

rax    0x0
rbx    0xc000040710
rcx    0x0
rdx    0x0
rdi    0x0
rsi    0x1f08000c
rbp    0x70000386def0
rsp    0x70000386deb0
r8     0x0
r9     0x0
r10    0x0
r11    0x0
r12    0x6b055b0
r13    0x0
r14    0x412a266
r15    0x0
rip    0x7fff34bb28a1
rflags 0x10202
cs     0x2b
fs     0x0
gs     0x0
exit status 2

Running with metal the same as above works, and looks like this:

% go run -tags=metal,example ./shiny/example/basic
# github.com/go-gl/glfw/v3.2/glfw
In file included from ../../pkg/mod/github.com/go-gl/glfw@v0.0.0-20190409004039-e6da0acd62b1/v3.2/glfw/c_glfw_darwin.go:8:
../../pkg/mod/github.com/go-gl/glfw@v0.0.0-20190409004039-e6da0acd62b1/v3.2/glfw/glfw/src/cocoa_window.m:989:9: warning: multiple methods named 'center' found [-Wobjc-multiple-method-names]
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSCollectionViewCompositionalLayout.h:601:19: note: using
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:312:1: note: also found
got lifecycle.Event{From:StageDead, To:StageFocused, DrawContext:<nil>}
got size.Event{WidthPx:1024, HeightPx:768, WidthPt:0, HeightPt:0, PixelsPerPt:0, Orientation:0}
got paint.Event{External:true}
got mouse.Event{X:-1950.5859, Y:1079.5234, Button:0, Modifiers:0x0, Direction:0x0}
got mouse.Event{X:-1934.4062, Y:1070.5312, Button:0, Modifiers:0x0, Direction:0x0}
got mouse.Event{X:-1910.0469, Y:1055.0234, Button:0, Modifiers:0x0, Direction:0x0}
got mouse.Event{X:-1852.5469, Y:1023.0703, Button:0, Modifiers:0x0, Direction:0x0}
got mouse.Event{X:-1789.1719, Y:989.71094, Button:0, Modifiers:0x0, Direction:0x0}
got mouse.Event{X:-1628.25, Y:906.64844, Button:0, Modifiers:0x0, Direction:0x0}
...

Screen Shot 2019-10-26 at 12 23 16 PM

@leighmcculloch
Copy link
Contributor Author

I updated the MacBook 2017 to macOS 10.15 (19A602), but the behavior is the same on it. Without metal SIGILLs, with metal a black screen.

@dmitshur
Copy link
Contributor

Thanks a lot for providing all that information Leigh.

I updated my Xcode from 10.3:

$ xcodebuild -version
Xcode 10.3
Build version 10G8

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

To Xcode 11.1:

$ xcodebuild -version
Xcode 11.1
Build version 11A1027

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

And I can reproduce the SIGILL: illegal instruction issue with gldriver:


$ go run -tags='example' ./example/basic
SIGILL: illegal instruction
PC=0x7fff39f3a8a1 m=5 sigcode=1
signal arrived during cgo execution

goroutine 7 [syscall, locked to thread]:
runtime.cgocall(0x40c4300, 0xc000048710, 0x0)
	/usr/local/go/src/runtime/cgocall.go:128 +0x5b fp=0xc0000486e0 sp=0xc0000486a8 pc=0x400550b
golang.org/x/exp/shiny/driver/gldriver._Cfunc_makeCurrentContext(0x453d4c0)
	_cgo_gotypes.go:298 +0x41 fp=0xc000048710 sp=0xc0000486e0 pc=0x40bf381
golang.org/x/exp/shiny/driver/gldriver.drawLoop(0xc0000a0000, 0x1)
	/Users/dmitri/go/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:147 +0x60 fp=0xc0000487d0 sp=0xc000048710 pc=0x40c0430
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1357 +0x1 fp=0xc0000487d8 sp=0xc0000487d0 pc=0x4058b01
created by golang.org/x/exp/shiny/driver/gldriver.preparedOpenGL
	/Users/dmitri/go/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:92 +0xe4

goroutine 1 [chan receive, locked to thread]:
golang.org/x/exp/shiny/driver/gldriver.drawgl(0x4356a90)
	/Users/dmitri/go/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:134 +0x15e
golang.org/x/exp/shiny/driver/gldriver._cgoexpwrap_db502a3a14da_drawgl(0x4356a90)
	_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(0x4116d38, 0xc000059f50, 0x4007dff)
	/Users/dmitri/go/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:107 +0x4d
golang.org/x/exp/shiny/driver/gldriver.Main(0x4116d38)
	/Users/dmitri/go/src/golang.org/x/exp/shiny/driver/gldriver/gldriver.go:26 +0x2f
golang.org/x/exp/shiny/driver.main(...)
	/Users/dmitri/go/src/golang.org/x/exp/shiny/driver/driver_darwin.go:15
golang.org/x/exp/shiny/driver.Main(...)
	/Users/dmitri/go/src/golang.org/x/exp/shiny/driver/driver.go:24
main.main()
	/Users/dmitri/go/src/golang.org/x/exp/shiny/example/basic/main.go:44 +0x2e

goroutine 6 [chan receive]:
golang.org/x/mobile/gl.(*context).enqueue(0xc0000a4000, 0x57, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/Users/dmitri/go/src/golang.org/x/mobile/gl/work.go:111 +0xd3
golang.org/x/mobile/gl.(*context).IsProgram(0xc0000a4000, 0x5ab00, 0x68)
	/Users/dmitri/go/src/golang.org/x/mobile/gl/gl.go:1045 +0xcb
golang.org/x/exp/shiny/driver/gldriver.(*screenImpl).NewTexture(0x41e8220, 0x100, 0x100, 0x0, 0x0, 0x0, 0x0)
	/Users/dmitri/go/src/golang.org/x/exp/shiny/driver/gldriver/screen.go:78 +0x1a0
main.main.func1(0x412e7c0, 0x41e8220)
	/Users/dmitri/go/src/golang.org/x/exp/shiny/example/basic/main.go:61 +0x267
golang.org/x/exp/shiny/driver/gldriver.driverStarted.func1()
	/Users/dmitri/go/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:114 +0x40
created by golang.org/x/exp/shiny/driver/gldriver.driverStarted
	/Users/dmitri/go/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:113 +0x35

rax    0x0
rbx    0xc000048710
rcx    0x0
rdx    0x0
rdi    0x0
rsi    0x1f08000c
rbp    0x70000be6aef0
rsp    0x70000be6aeb0
r8     0x0
r9     0x0
r10    0x0
r11    0x0
r12    0x453d4c0
r13    0x0
r14    0x40315d0
r15    0x0
rip    0x7fff39f3a8a1
rflags 0x10202
cs     0x2b
fs     0x0
gs     0x0
exit status 2

For the record, I'm also on the latest macOS Catalina 10.15 (19A602).

I still can't reproduce the issue with Metal, that seems to still work okay. I suspect it may be a separate issue somehow related to the difference in hardware and drivers.

@dmitshur dmitshur changed the title x/exp/shiny: SIGILL: illegal instruction on macOS Catalina running basic example x/exp/shiny: SIGILL: illegal instruction on macOS Catalina with Xcode 11.1 running basic example Oct 26, 2019
@leighmcculloch
Copy link
Contributor Author

Is it worth me opening an issue for the Metal issue given that the MacBook line has been discontinued? I can open a separate issue for it, but I don't want to if it's unlikely to get looked at. The bigger issue is the OpenGL driver not working with latest Xcode I think.

@dmitshur
Copy link
Contributor

dmitshur commented Oct 27, 2019

Is it worth me opening an issue for the Metal issue given that the MacBook line has been discontinued?

It would be helpful.

  • If someone else runs into the same problem, they'll be able to find it and know it's not just them.
  • They no longer make new 12-inch MacBook models, but the 2017 MacBook is still relatively recent and supported.
  • The Metal platform is supposed to be pretty consistent across different devices, so if there's a problem affecting one device, it's likely a legitimate issue.

We can put it in Backlog milestone so it's clear that it'll be fixed whenever someone gets around to it.

@dmitshur
Copy link
Contributor

dmitshur commented Oct 29, 2019

I tried to create a smaller reproducer for this, but haven't been able to successfully do that yet.


So far, the following program isn't enough to reproduce the issue.

main.go

// +build darwin,amd64,!ios

// Try to create a smaller reproducer for golang.org/issue/35177.
package main

/*
#cgo CFLAGS: -x objective-c -DGL_SILENCE_DEPRECATION
#cgo LDFLAGS: -framework Foundation -framework Metal
#include <OpenGL/gl3.h>
#include <stdlib.h>

void run();
void makeCurrentContext(uintptr_t ctx);
*/
import "C"

import (
	"runtime"
	"time"
)

func init() {
	runtime.LockOSThread()
}

func main() {
	C.run()
	time.Sleep(time.Second)
}

//export preparedOpenGL
func preparedOpenGL(ctx uintptr) {
	w := &windowImpl{
		ctx: ctx,
	}
	go drawLoop(w)
}

type windowImpl struct {
	// ctx is a C data structure for the GL context.
	//	- Cocoa:   uintptr holding a NSOpenGLContext*.
	//	- X11:     uintptr holding an EGLSurface.
	//	- Windows: ctxWin32
	ctx interface{}
}

func drawLoop(w *windowImpl) {
	runtime.LockOSThread()
	C.makeCurrentContext(C.uintptr_t(w.ctx.(uintptr)))
}

main.m

// +build darwin,amd64,!ios

#include "_cgo_export.h"
#include <pthread.h>
#include <stdio.h>

#import <Cocoa/Cocoa.h>
#import <Foundation/Foundation.h>
#import <OpenGL/gl3.h>

//#import <Foundation/NSObjCRuntime.h>
//#import <Metal/Metal.h>

void run() {
	NSOpenGLContext *ctx = NULL;
	preparedOpenGL((GoUintptr)ctx);
}

void makeCurrentContext(uintptr_t context) {
	NSOpenGLContext* ctx = (NSOpenGLContext*)context;
	NSLog(@"%@", ctx);
}

@ianlancetaylor I suspect it may be a problem in gcc (aka clang) that comes with Xcode 11.1, or a bug in cgo that is being triggered by a change in gcc. Do you have suggestions for how to investigate a potential cgo bug?

@ianlancetaylor
Copy link
Contributor

For a problem like this the first step is definitely to reproduce the problem.

@leighmcculloch If you can reproduce the problem, see if you can reproduce it under the debugger, and show us the instruction that is executing when the SIGILL signal occurs. Thanks.

@dmitshur
Copy link
Contributor

To clarify, both @leighmcculloch and I can reproduce the SIGILL problem using golang.org/x/exp/shiny/example/basic. I just haven't been able to reproduce it with a smaller snippet yet.

I'll try that, thanks Ian.

@ianlancetaylor
Copy link
Contributor

Yes, for something like this the size of the reproduction case is unlikely to matter, as long as we can reproduce it reliably.

@dmitshur
Copy link
Contributor

I'm able to get this:

shiny $ dlv --build-flags='-tags=example' debug ./example/basic
Type 'help' for list of commands.
(dlv) continue
Stopped at: 0x7fff73df88f6
=>no source available
Command failed: bad instruction
(dlv) disassemble -a 0x7fff73df88e6 0x7fff73df8906
	.:0	0x7fff73df88e6	415e		pop r14
	.:0	0x7fff73df88e8	415f		pop r15
	.:0	0x7fff73df88ea	5d		pop rbp
	.:0	0x7fff73df88eb	c3		ret
	.:0	0x7fff73df88ec	b831010002	mov eax, 0x2000131
	.:0	0x7fff73df88f1	4989ca		mov r10, rcx
	.:0	0x7fff73df88f4	0f05		syscall
=>	.:0	0x7fff73df88f6	7308		jnb 0x7fff73df8900
	.:0	0x7fff73df88f8	4889c7		mov rdi, rax
	.:0	0x7fff73df88fb	e997caffff	jmp 0x7fff73df5397
	.:0	0x7fff73df8900	c3		ret
	.:0	0x7fff73df8901	90		nop
	.:0	0x7fff73df8902	90		nop
	.:0	0x7fff73df8903	90		nop
	.:0	0x7fff73df8904	b8		prefix(0xb8)
	.:0	0x7fff73df8905	2f		?
(dlv) 

Is it helpful?

@randall77
Copy link
Contributor

Yes, helpful. Or at least, illuminating. But confusing nontheless.

The instruction at the PC is not invalid. That's a perfectly fine instruction and should never SIGILL.

But it is right after a syscall. Maybe that syscall is raising the SIGILL for some reason.
That sycall number (0x2000131 = 1<<25 + 305) is for the psynch_cvwait sycall, which seems to be used to implement pthread_cond_wait. I don't understand why that would raise a SIGILL.

(If the SIGILL was raised by the syscall, would it appear at the next instruction or on the syscall instruction itself? I'm not sure how that works.)

@ianlancetaylor
Copy link
Contributor

I think this is what one would expect to see if the SIGILL were sent by a kill system call or if it were raised on a thread that had SIGILL blocked, and if the SIGILL were picked up by the kernel as it returned from the psynch_cvwait call.

@ianlancetaylor
Copy link
Contributor

The sigcode=1 for SIGILL should be ILL_ILLOPC, meaning an invalid opcode. It's not SI_USER, so this signal was not sent by a kill system call. A Go program should always unblock SIGILL. So I have to admit that I don't understand what is going on here.

I don't entirely trust delve to get this kind of detail right. Can you double-check with gdb or lldb? Thanks.

@randall77
Copy link
Contributor

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

@dmitshur
Copy link
Contributor

dmitshur commented Oct 30, 2019

Thank you for the guidance.

I've tried lldb and 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:

shiny $ go build -tags=example ./example/basic
shiny $ lldb basic
(lldb) target create "basic"
Current executable set to 'basic' (x86_64).
(lldb) run
Process 3562 launched: '/Users/dmitri/go/src/golang.org/x/exp/shiny/basic' (x86_64)
2019-10-30 08:34:05.411545-0400 basic[3562:110884] flock failed to lock maps file: errno = 35
2019-10-30 08:34:05.412054-0400 basic[3562:110884] flock failed to lock maps file: errno = 35
Process 3562 stopped
* thread #5, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x00007fff379c0a04 AppKit`-[NSOpenGLContext update] + 520
AppKit`-[NSOpenGLContext update]:
->  0x7fff379c0a04 <+520>: ud2    
    0x7fff379c0a06 <+522>: movq   %rax, %r14
    0x7fff379c0a09 <+525>: jmp    0x7fff379c0a12            ; <+534>
    0x7fff379c0a0b <+527>: movq   %rax, %r14
Target 0: (basic) stopped.
(lldb) bt
* thread #5, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x00007fff379c0a04 AppKit`-[NSOpenGLContext update] + 520
    frame #1: 0x00000000040580e0 basic`runtime.asmcgocall + 112
    frame #2: 0x0000000004031476 basic`runtime.mstart + 102
    frame #3: 0x00000000040c67ed basic`crosscall_amd64 + 12
    frame #4: 0x00000000040c6474 basic`threadentry + 36
    frame #5: 0x00007fff71b30d36 libsystem_pthread.dylib`_pthread_start + 125
    frame #6: 0x00007fff71b2d58f libsystem_pthread.dylib`thread_start + 15

Instructions before the offending one:

    0x7fff379c09f8 <+508>: leaq   0x855dcc(%rip), %rdi      ; "-[NSOpenGLContext update] must be called from the main thread if the context has a view."
    0x7fff379c09ff <+515>: callq  0x7fff381a07e8            ; symbol stub for: _os_crash
->  0x7fff379c0a04 <+520>: ud2    
Full disassembly
(lldb) dis
AppKit`-[NSOpenGLContext update]:
    0x7fff379c07fc <+0>:   pushq  %rbp
    0x7fff379c07fd <+1>:   movq   %rsp, %rbp
    0x7fff379c0800 <+4>:   pushq  %r15
    0x7fff379c0802 <+6>:   pushq  %r14
    0x7fff379c0804 <+8>:   pushq  %r13
    0x7fff379c0806 <+10>:  pushq  %r12
    0x7fff379c0808 <+12>:  pushq  %rbx
    0x7fff379c0809 <+13>:  subq   $0x18, %rsp
    0x7fff379c080d <+17>:  movq   %rdi, %r12
    0x7fff379c0810 <+20>:  movq   0x5b1e4329(%rip), %rsi    ; "lock"
    0x7fff379c0817 <+27>:  callq  *0x5aee419b(%rip)         ; (void *)0x00007fff705b5040: objc_msgSend
    0x7fff379c081d <+33>:  leaq   0x8(%r12), %rdi
    0x7fff379c0822 <+38>:  movq   %rdi, -0x38(%rbp)
    0x7fff379c0826 <+42>:  callq  0x7fff381a0da0            ; symbol stub for: objc_loadWeak
    0x7fff379c082b <+47>:  movq   %rax, -0x40(%rbp)
    0x7fff379c082f <+51>:  testq  %rax, %rax
    0x7fff379c0832 <+54>:  je     0x7fff379c096d            ; <+369>
    0x7fff379c0838 <+60>:  movb   0x5b266802(%rip), %al     ; sNSOpenGLContextSuppressThreadAssertionsComputedValue
    0x7fff379c083e <+66>:  testb  %al, %al
    0x7fff379c0840 <+68>:  je     0x7fff379c09d0            ; <+468>
    0x7fff379c0846 <+74>:  addb   $-0x2, %al
    0x7fff379c0848 <+76>:  testb  %al, %al
    0x7fff379c084a <+78>:  jne    0x7fff379c0859            ; <+93>
    0x7fff379c084c <+80>:  callq  0x7fff381a0f56            ; symbol stub for: pthread_main_np
    0x7fff379c0851 <+85>:  testl  %eax, %eax
    0x7fff379c0853 <+87>:  je     0x7fff379c09f8            ; <+508>
    0x7fff379c0859 <+93>:  movq   %r12, %rdi
    0x7fff379c085c <+96>:  callq  0x7fff37d0617c            ; NSOpenGLContextSetLayerOnViewIfNecessary
    0x7fff379c0861 <+101>: movq   -0x38(%rbp), %rdi
    0x7fff379c0865 <+105>: callq  0x7fff381a0da0            ; symbol stub for: objc_loadWeak
    0x7fff379c086a <+110>: movq   %rax, %rbx
    0x7fff379c086d <+113>: movq   0x5b1fa23c(%rip), %rsi    ; "_managesOpenGLDrawable"
    0x7fff379c0874 <+120>: movq   %rax, %rdi
    0x7fff379c0877 <+123>: callq  *0x5aee413b(%rip)         ; (void *)0x00007fff705b5040: objc_msgSend
    0x7fff379c087d <+129>: xorl   %r15d, %r15d
    0x7fff379c0880 <+132>: movl   $0x0, -0x2c(%rbp)
    0x7fff379c0887 <+139>: movl   $0x0, %r14d
    0x7fff379c088d <+145>: movl   $0x0, -0x30(%rbp)
    0x7fff379c0894 <+152>: testb  %al, %al
    0x7fff379c0896 <+154>: jne    0x7fff379c08bd            ; <+193>
    0x7fff379c0898 <+156>: movq   0x5b1e8d81(%rip), %rsi    ; "_isLayerBacked"
    0x7fff379c089f <+163>: movq   %rbx, %rdi
    0x7fff379c08a2 <+166>: callq  *0x5aee4110(%rip)         ; (void *)0x00007fff705b5040: objc_msgSend
    0x7fff379c08a8 <+172>: movl   %eax, %r14d
    0x7fff379c08ab <+175>: testb  %al, %al
    0x7fff379c08ad <+177>: sete   %r15b
    0x7fff379c08b1 <+181>: setne  %al
    0x7fff379c08b4 <+184>: movl   %eax, -0x2c(%rbp)
    0x7fff379c08b7 <+187>: movl   %r15d, %eax
    0x7fff379c08ba <+190>: movl   %eax, -0x30(%rbp)
    0x7fff379c08bd <+193>: movq   %r12, %rdi
    0x7fff379c08c0 <+196>: callq  0x7fff379b7d41            ; _NSOpenGLContextGetOnScreenSurface
    0x7fff379c08c5 <+201>: movq   %rax, %rbx
    0x7fff379c08c8 <+204>: movq   %r12, %rdi
    0x7fff379c08cb <+207>: callq  0x7fff379b7d91            ; _NSOpenGLContextGetOffScreenSurface
    0x7fff379c08d0 <+212>: movq   %rax, %r13
    0x7fff379c08d3 <+215>: testq  %rbx, %rbx
    0x7fff379c08d6 <+218>: sete   %al
    0x7fff379c08d9 <+221>: orb    %r15b, %al
    0x7fff379c08dc <+224>: jne    0x7fff379c08ec            ; <+240>
    0x7fff379c08de <+226>: movsbl %r14b, %esi
    0x7fff379c08e2 <+230>: movq   %r12, %rdi
    0x7fff379c08e5 <+233>: callq  0x7fff37a12036            ; NSOpenGLContextDetachOnScreenViewSurface
    0x7fff379c08ea <+238>: xorl   %ebx, %ebx
    0x7fff379c08ec <+240>: testq  %r13, %r13
    0x7fff379c08ef <+243>: sete   %al
    0x7fff379c08f2 <+246>: orb    -0x2c(%rbp), %al
    0x7fff379c08f5 <+249>: jne    0x7fff379c0906            ; <+266>
    0x7fff379c08f7 <+251>: movzbl -0x30(%rbp), %esi
    0x7fff379c08fb <+255>: movq   %r12, %rdi
    0x7fff379c08fe <+258>: callq  0x7fff37a0bd74            ; NSOpenGLContextDetachOffScreenViewSurface
    0x7fff379c0903 <+263>: xorl   %r13d, %r13d
    0x7fff379c0906 <+266>: testq  %rbx, %rbx
    0x7fff379c0909 <+269>: jne    0x7fff379c0924            ; <+296>
    0x7fff379c090b <+271>: xorb   $0x1, %r15b
    0x7fff379c090f <+275>: jne    0x7fff379c0924            ; <+296>
    0x7fff379c0911 <+277>: movq   %r12, %rdi
    0x7fff379c0914 <+280>: callq  0x7fff379bfe79            ; NSOpenGLContextAttachOnScreenViewSurface
    0x7fff379c0919 <+285>: movq   %r12, %rdi
    0x7fff379c091c <+288>: callq  0x7fff379b7d41            ; _NSOpenGLContextGetOnScreenSurface
    0x7fff379c0921 <+293>: movq   %rax, %rbx
    0x7fff379c0924 <+296>: testq  %r13, %r13
    0x7fff379c0927 <+299>: jne    0x7fff379c0943            ; <+327>
    0x7fff379c0929 <+301>: movl   -0x2c(%rbp), %eax
    0x7fff379c092c <+304>: xorb   $0x1, %al
    0x7fff379c092e <+306>: jne    0x7fff379c0943            ; <+327>
    0x7fff379c0930 <+308>: movq   %r12, %rdi
    0x7fff379c0933 <+311>: callq  0x7fff379b7e76            ; NSOpenGLContextAttachOffScreenViewSurface
    0x7fff379c0938 <+316>: movq   %r12, %rdi
    0x7fff379c093b <+319>: callq  0x7fff379b7d91            ; _NSOpenGLContextGetOffScreenSurface
    0x7fff379c0940 <+324>: movq   %rax, %r13
    0x7fff379c0943 <+327>: testq  %rbx, %rbx
    0x7fff379c0946 <+330>: je     0x7fff379c0979            ; <+381>
    0x7fff379c0948 <+332>: movq   -0x38(%rbp), %rdi
    0x7fff379c094c <+336>: callq  0x7fff381a0da0            ; symbol stub for: objc_loadWeak
    0x7fff379c0951 <+341>: movq   0x5b1fa1a0(%rip), %rsi    ; "_syncSurfaceIfPostponed"
    0x7fff379c0958 <+348>: movq   %rax, %rdi
    0x7fff379c095b <+351>: callq  *0x5aee4057(%rip)         ; (void *)0x00007fff705b5040: objc_msgSend
    0x7fff379c0961 <+357>: movq   0x10(%r12), %rdi
    0x7fff379c0966 <+362>: callq  0x7fff3819e592            ; symbol stub for: CGLUpdateContext
    0x7fff379c096b <+367>: jmp    0x7fff379c0986            ; <+394>
    0x7fff379c096d <+369>: movq   0x10(%r12), %rdi
    0x7fff379c0972 <+374>: callq  0x7fff3819e592            ; symbol stub for: CGLUpdateContext
    0x7fff379c0977 <+379>: jmp    0x7fff379c09ab            ; <+431>
    0x7fff379c0979 <+381>: testq  %r13, %r13
    0x7fff379c097c <+384>: je     0x7fff379c0986            ; <+394>
    0x7fff379c097e <+386>: movq   %r12, %rdi
    0x7fff379c0981 <+389>: callq  0x7fff37d06bd1            ; NSOpenGLContextUpdateOffScreenViewSurface
    0x7fff379c0986 <+394>: movq   0x5b1fa113(%rip), %rsi    ; "wantsBestResolutionOpenGLSurface"
    0x7fff379c098d <+401>: movq   -0x40(%rbp), %rdi
    0x7fff379c0991 <+405>: callq  *0x5aee4021(%rip)         ; (void *)0x00007fff705b5040: objc_msgSend
    0x7fff379c0997 <+411>: testb  %al, %al
    0x7fff379c0999 <+413>: je     0x7fff379c09ab            ; <+431>
    0x7fff379c099b <+415>: movq   0x5b1fa106(%rip), %rsi    ; "_updateOpenGLViewport"
    0x7fff379c09a2 <+422>: movq   %r12, %rdi
    0x7fff379c09a5 <+425>: callq  *0x5aee400d(%rip)         ; (void *)0x00007fff705b5040: objc_msgSend
    0x7fff379c09ab <+431>: xorl   %ebx, %ebx
    0x7fff379c09ad <+433>: movq   0x5b1e4194(%rip), %rsi    ; "unlock"
    0x7fff379c09b4 <+440>: movq   %r12, %rdi
    0x7fff379c09b7 <+443>: callq  *0x5aee3ffb(%rip)         ; (void *)0x00007fff705b5040: objc_msgSend
    0x7fff379c09bd <+449>: testb  %bl, %bl
    0x7fff379c09bf <+451>: jne    0x7fff379c09f1            ; <+501>
    0x7fff379c09c1 <+453>: addq   $0x18, %rsp
    0x7fff379c09c5 <+457>: popq   %rbx
    0x7fff379c09c6 <+458>: popq   %r12
    0x7fff379c09c8 <+460>: popq   %r13
    0x7fff379c09ca <+462>: popq   %r14
    0x7fff379c09cc <+464>: popq   %r15
    0x7fff379c09ce <+466>: popq   %rbp
    0x7fff379c09cf <+467>: retq   
    0x7fff379c09d0 <+468>: leaq   0x5af42641(%rip), %rdi    ; @"NSOpenGLContextSuppressThreadAssertions"
    0x7fff379c09d7 <+475>: leaq   0x5b266662(%rip), %rdx    ; sNSOpenGLContextSuppressThreadAssertionsComputedValue
    0x7fff379c09de <+482>: leaq   0x3461d3(%rip), %rcx      ; NSOpenGLContextSuppressThreadAssertionsDefaultValueFunction
    0x7fff379c09e5 <+489>: xorl   %esi, %esi
    0x7fff379c09e7 <+491>: callq  0x7fff376437c7            ; _NSGetBoolAppConfig
    0x7fff379c09ec <+496>: jmp    0x7fff379c0848            ; <+76>
    0x7fff379c09f1 <+501>: callq  0x7fff381a0d70            ; symbol stub for: objc_exception_rethrow
    0x7fff379c09f6 <+506>: ud2    
    0x7fff379c09f8 <+508>: leaq   0x855dcc(%rip), %rdi      ; "-[NSOpenGLContext update] must be called from the main thread if the context has a view."
    0x7fff379c09ff <+515>: callq  0x7fff381a07e8            ; symbol stub for: _os_crash
->  0x7fff379c0a04 <+520>: ud2    
    0x7fff379c0a06 <+522>: movq   %rax, %r14
    0x7fff379c0a09 <+525>: jmp    0x7fff379c0a12            ; <+534>
    0x7fff379c0a0b <+527>: movq   %rax, %r14
    0x7fff379c0a0e <+530>: testb  %bl, %bl
    0x7fff379c0a10 <+532>: je     0x7fff379c0a17            ; <+539>
    0x7fff379c0a12 <+534>: callq  0x7fff381a0d64            ; symbol stub for: objc_end_catch
    0x7fff379c0a17 <+539>: movq   %r14, %rdi
    0x7fff379c0a1a <+542>: callq  0x7fff381a070a            ; symbol stub for: _Unwind_Resume
    0x7fff379c0a1f <+547>: ud2    
    0x7fff379c0a21 <+549>: callq  0x7fff381a0e42            ; symbol stub for: objc_terminate
    0x7fff379c0a26 <+554>: movq   %rax, %rdi
    0x7fff379c0a29 <+557>: callq  0x7fff381a0d40            ; symbol stub for: objc_begin_catch
    0x7fff379c0a2e <+562>: movb   $0x1, %bl
    0x7fff379c0a30 <+564>: jmp    0x7fff379c09ad            ; <+433>
    0x7fff379c0a35 <+569>: nop    
    0x7fff379c0a36 <+570>: nop    
    0x7fff379c0a37 <+571>: nop    
    0x7fff379c0a38 <+572>: nop    
    0x7fff379c0a39 <+573>: nop    
    0x7fff379c0a3a <+574>: nop    
    0x7fff379c0a3b <+575>: nop    
(lldb) 

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 gldriver implementation.

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?)

@ianlancetaylor
Copy link
Contributor

Thank for the extra information. That does make more sense.

The ud2 is from C code compiled by Apple. That is typically generated by C compilers for calls to __builtin_trap or __builtin_unreachable.

I agree that this does look like a missing runtime.LockOSThread somewhere.

@randall77
Copy link
Contributor

Why does _os_crash return? That sounds like the kind of function that shouldn't.

@ianlancetaylor
Copy link
Contributor

That is how it is implemented. The program actually uses the os_crash macro, which calls __os_crash. The _os_crash function sets a message (not sure what that does) and calls an optional callback. Then it returns. The definition in os/assumes.h is

#define os_crash(msg) \
	({		 \
		_os_crash(msg);			\
		os_hardware_trap();		\
	})

#define os_hardware_trap() __asm__ __volatile__ (""); __builtin_trap()

@gordonklaus
Copy link
Contributor

@dmitshur

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 gldriver implementation.

It does indeed seem to be relevant. Changing this line from
[ctx update];
to
[ctx performSelectorOnMainThread:@selector(update) withObject:nil waitUntilDone:YES];
fixes the problem.

@dmitshur
Copy link
Contributor

Thanks for the hint @gordonklaus, it was very helpful.

The change you suggested sounded very promising. I tried it, and while it causes prevents the crash from happening, it also causes the program to deadlock. The application window never appears.

Using waitUntilDone:NO prevents the deadlock.

However, I realize now that [ctx update]; is not necessary for the main purpose of makeCurrentContext and can be taken out. It was added in CL 154461 and I suspect that change is faulty, it's not thread safe to call [ctx update]; inside the makeCurrentContext function.

I'm not observing any adverse effects with [ctx update]; outright removed on Catalina.

I plan to fix this problem by reverting CL 154461 for now. If it needs to be re-added, it should be done in a thread-safe way.

/cc @eaburns Are you able to reproduce the problem you observed that CL 154461 was aiming to resolve? Do you know if it is reproducible on macOS Catalina?

@gopherbot
Copy link

Change https://golang.org/cl/212245 mentions this issue: shiny/driver/gldriver: revert "update the open gl context after making it current"

@dmitshur dmitshur self-assigned this Dec 21, 2019
@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 21, 2019
@golang golang locked and limited conversation to collaborators Dec 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-Darwin
Projects
None yet
Development

No branches or pull requests

6 participants