-
Notifications
You must be signed in to change notification settings - Fork 182
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
v3.3/glfw: CreateWindow crashes after WaitEvents on macOS #262
Comments
gopherbot
pushed a commit
to golang/exp
that referenced
this issue
Nov 27, 2019
GLFW v3.2 was old and started generating some warnings on macOS 10.15 Catalina (and warnings get upgraded to errors on builders). Update to GLFW v3.3 that was recently released to resolve the problem. There is a small regression affecting the newer version of GLFW that is being tracked in issues glfw/glfw#1543 and go-gl/glfw#262. It causes the application to crash when glfwWaitEvents is called before the first window is opened: $ go run -tags='example metal' .../shiny/example/basic 2019-11-25 22:19:24.715 basic[9412:69556] *** Assertion failure in -[NSApplication run], /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1894.10.126/AppKit.subproj/NSApplication.m:3313 2019-11-25 22:19:24.715 basic[9412:69556] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSApp with wrong _running count' *** First throw call stack: ( 0 CoreFoundation 0x00007fff30503f53 __exceptionPreprocess + 250 1 libobjc.A.dylib 0x00007fff665c9835 objc_exception_throw + 48 2 CoreFoundation 0x00007fff3051f810 +[NSException raise:format:arguments:] + 88 3 Foundation 0x00007fff32bff5d1 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 191 4 AppKit 0x00007fff2d657ed3 -[NSApplication run] + 1007 5 basic 0x00000000040d473d _glfwPlatformCreateWindow + 77 6 basic 0x00000000040cd945 glfwCreateWindow + 485 7 basic 0x00000000040da71b _cgo_78603e0816ec_Cfunc_glfwCreateWindow + 43 8 basic 0x0000000004058430 runtime.asmcgocall + 112 ) libc++abi.dylib: terminating with uncaught exception of type NSException SIGABRT: abort PC=0x7fff67a7b49a m=0 sigcode=0 signal arrived during cgo execution [...] Work around it by waiting for the first window open request before entering the main loop. That way, glfwWaitEvents is not called before a window has been created, and the crash does not occur. This temporary workaround can be removed after the bug is fixed. Fixes golang/go#35766 Updates go-gl/glfw#256 Updates glfw/glfw#1543 Updates go-gl/glfw#262 Change-Id: Ie9b15ab6632af39871d94993a3e3097ea798a7e2 Reviewed-on: https://go-review.googlesource.com/c/exp/+/208877 Reviewed-by: Brad Fitzpatrick <[email protected]>
dmitshur
added a commit
that referenced
this issue
Feb 16, 2020
GLFW 3.3.2 was released on January 20, 2020. See https://github.com/glfw/glfw/releases/tag/3.3.2. Done using steps from https://github.com/go-gl/glfw/wiki/Development#updating-glfw-c-source: rm -rf ./glfw/ git clone --depth 1 --branch latest https://github.com/glfw/glfw # 'latest' branch points to latest stable release. cd ./glfw/ git rev-parse HEAD > ../GLFW_C_REVISION.txt # Only keep the needed sources files in ./src, ./include and ./deps. rm -rf ./.git rm -rf ./.gitignore rm -rf ./.gitattributes rm -rf ./.mailmap rm -rf ./.appveyor.yml rm -rf ./.github rm -rf ./.travis.yml rm -rf ./CMake rm -rf ./CMakeLists.txt rm -rf ./src/CMakeLists.txt rm -rf ./src/*.in rm -rf ./README.md rm -rf ./cmake_uninstall.cmake.in rm -rf ./docs rm -rf ./examples rm -rf ./tests Fixes #262.
This was referenced Feb 20, 2020
Closed
gopherbot
pushed a commit
to golang/exp
that referenced
this issue
Feb 24, 2020
Update to a newer v3.3/glfw pseudo-version, which uses GLFW 3.3.2. GLFW 3.3.2 includes a fix for glfw/glfw#1543 (go-gl/glfw#262), which makes it possible to remove the workaround for it from mtldriver. However, there is a new regression glfw/glfw#1649 (go-gl/glfw#272). Fortunately, it's a smaller issue. Add a temporary workaround for it. Also update comment in two internal packages. The upstream names were modified in https://dmitri.shuralyov.com/gpu/mtl/...$commit/11308bd612348edeca0d8fddca07bc5a4dfbb35c to match the names used here. Change-Id: I3199f16890efd539d62d8914b92260f8a614449a Reviewed-on: https://go-review.googlesource.com/c/exp/+/220639 Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Hajime Hoshi <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is the
golang.org/go-gl/glfw/v3.3/glfw
tracking bug for upstream GLFW issue glfw/glfw#1543. It can be reproduced with the following Go program:Running it on macOS 10.15.1 with Xcode 11.2.1 produces the following crash:
To make progress here, we need to resolve glfw/glfw#1543 first and then pull in the fix into
golang.org/go-gl/glfw/v3.3/glfw
.The text was updated successfully, but these errors were encountered: