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

glfwCreateWindow crashes after polling event on mac #1543

Open
mtiat opened this issue Jul 31, 2019 · 6 comments
Assignees
Labels

Comments

@mtiat
Copy link

@mtiat mtiat commented Jul 31, 2019

#include <GLFW/glfw3.h>
#include <iostream>

int main()
{
    assert(glfwInit());

    glfwPostEmptyEvent();
    glfwWaitEvents();

    glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_API);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
    glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
    glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);

    glfwCreateWindow(500, 500, "ff", nullptr, nullptr);
}

Error


2019-07-31 21:01:15.534 sfm_prototype[36885:1955879] *** Assertion failure in -[NSApplication run], /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1671.40.119/AppKit.subproj/NSApplication.m:3537
2019-07-31 21:01:15.535 sfm_prototype[36885:1955879] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSApp with wrong _running count'
*** First throw call stack:
(
0   CoreFoundation                      0x00007fff4a352cf9 __exceptionPreprocess + 256
1   libobjc.A.dylib                     0x00007fff74ee7a17 objc_exception_throw + 48
2   CoreFoundation                      0x00007fff4a36da16 +[NSException raise:format:arguments:] + 98
3   Foundation                          0x00007fff4c5ffe11 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 194
4   AppKit                              0x00007fff4791c01b -[NSApplication run] + 1062
5   libglfw.3.dylib                     0x000000010bcf2804 _glfwPlatformCreateWindow + 81
6   libglfw.3.dylib                     0x000000010bced533 glfwCreateWindow + 460
7   sfm_prototype                       0x000000010bb77821 main + 193
8   libdyld.dylib                       0x00007fff767153d5 start + 1
9   ???                                 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
@HugoPeters1024

This comment has been minimized.

Copy link

@HugoPeters1024 HugoPeters1024 commented Sep 3, 2019

Why do post and wait events before creating the window? I am not sure if that is the case but can imagine that that is in fact an invalid operation. Also you might want to call glfwMakeContextCurrent(GLFWwindow*) on your newly created window first to make sure the thread owns the OpenGL context.

The docs contain pretty compelling step by step tutorials include one for window handling:
https://www.glfw.org/docs/latest/window_guide.html

Helped me out a lot when getting started

@ShuangLiu1992

This comment has been minimized.

Copy link

@ShuangLiu1992 ShuangLiu1992 commented Oct 29, 2019

if you are running your app in release mode, the statement in assert will not execute hence glfwInit() might not have been called. just a guess

@elmindreda elmindreda added bug verified and removed support labels Oct 31, 2019
@elmindreda elmindreda self-assigned this Oct 31, 2019
@elmindreda

This comment has been minimized.

Copy link
Member

@elmindreda elmindreda commented Oct 31, 2019

Successfully reproduced with current master on macOS 10.14.6.

@dmitshur

This comment has been minimized.

Copy link
Collaborator

@dmitshur dmitshur commented Nov 26, 2019

Thanks for reporting this problem @mtiat. I ran into this as well when updating the Go package golang.org/x/exp/shiny/driver/mtldriver from GLFW v3.2 to v3.3, and this issue report helped me understand what happened more quickly.


Why do post and wait events before creating the window? I am not sure if that is the case but can imagine that that is in fact an invalid operation.

Documentation for both glfwWaitEvents and glfwPostEmptyEvent says:

If no windows exist, this function returns immediately. For synchronization of threads in applications that do not create windows, use your threading library of choice.

Also, https://www.glfw.org/docs/3.2/input_guide.html#events says:

There must be at least one GLFW window for glfwWaitEvents to sleep.

That means it should be valid to call them before the first window is created, but they both are expected to be no-ops (return right away without doing anything). The bug here is that they cause the application to crash.

In my situation, it happened because the application is multi-threaded while it tries to arrange so that GLFW calls are made on the main thread. It was previously incorrectly relying on glfwWaitEvents to sleep before the first window was created. See commit message of https://golang.org/cl/208877 for details.


@elmindreda Do I understand the API documentation correctly that the intention is for glfwWaitEvents to not sleep when there are zero open windows, even if a window was created and then later destroyed? That's the behavior I'm currently implementing in https://golang.org/cl/208877. Edit: Never mind, this question is no longer relevant for 3.3 and newer.

@dmitshur

This comment has been minimized.

Copy link
Collaborator

@dmitshur dmitshur commented Nov 26, 2019

I just noticed I was looking at the 3.2 docs, not 3.3 as I intended. The “If no windows exist, this function returns immediately. For synchronization of threads in applications that do not create windows, use your threading library of choice.” bit has been removed in GLFW 3.3 (which is great because it simplifies API use in my use case).

Edit: This change is mentioned in GLFW 3.3 release notes, see https://www.glfw.org/docs/3.3/news.html#wait_events_33.

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 <bradfitz@golang.org>
elmindreda added a commit that referenced this issue Nov 29, 2019
Polling the event queue before NSApp had been allowed to finish
launching, in our case by starting our self-terminating run loop,
triggered an assertion inside NSApplication.

This fix, which makes all event processing functions capable of starting
it, makes that assertion less likely.

A more Cocoa-friendly fix would be to finish launching NSApp during
glfwInit and let people annoyed by the menu bar disabled it with
GLFW_COCOA_MENUBAR.  That may not be suitable for 3.3-stable, though.

Fixes #1543.
@elmindreda

This comment has been minimized.

Copy link
Member

@elmindreda elmindreda commented Nov 29, 2019

Successfully reproduced with current master on OS X 10.10.5.

Proposed fix 4e469be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.