Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSApp with wrong _running count'

[stuartmscott]

Describe the bug:

Running the fyne test suite causes;

2020-03-29 13:20:15.724 glfw.test[56866:1179588] *** Assertion failure in -[NSApplication run], /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1894.40.150/AppKit.subproj/NSApplication.m:3313
2020-03-29 13:20:15.725 glfw.test[56866:1179588] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSApp with wrong _running count'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff320e2d07 __exceptionPreprocess + 250
	1   libobjc.A.dylib                     0x00007fff6ae075bf objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff3210bec8 +[NSException raise:format:arguments:] + 88
	3   Foundation                          0x00007fff347f6f3d -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 191
	4   AppKit                              0x00007fff2f2d434b -[NSApplication run] + 1007
	5   glfw.test                           0x00000000043b228d _glfwPlatformCreateWindow + 77
	6   glfw.test                           0x00000000043ab495 glfwCreateWindow + 485
	7   glfw.test                           0x00000000043b826b _cgo_8d6b35894ada_Cfunc_glfwCreateWindow + 43
	8   glfw.test                           0x000000000405f470 runtime.asmcgocall + 112
)
libc++abi.dylib: terminating with uncaught exception of type NSException
SIGABRT: abort
PC=0x7fff6c0f633a m=0 sigcode=0
signal arrived during cgo execution

Note: This is similar to #77 but the exception has a different reason.

To Reproduce:

Steps to reproduce the behaviour:

1. go test fyne.io/fyne/... (test appears flakey, may need to run tests multiple times)

Screenshots:

N/A

Example code:

N/A

Device (please complete the following information):

• OS: MacOS
• Version: 10.15.4 (Catalina)
• Go version: go1.13.8 darwin/amd64
• Fyne version: develop/a85639c2c5ffba3cbaf962a156b5961b3f3349d4

[andydotxyz]

Yes, I have seen this as well. According to the macOS documentation it is when an app is launched more than once (which is not supposed to happen on macOS). Not sure how, but I’m guessing there is missing cleanup in the internal/driver/glfw package (as that is the only place that real windows ever get loaded I think).

[stuartmscott]

Thanks Andy, I know we've talked about this before but I hit it, and the other flakey test, pretty much every time I work on Fyne so wanted to get issues filed so we can track them and hopefully get them fixed soon.

[andydotxyz]

Yes. Each major macOS update breaks things for us somehow :( the bigger issue is that menus don't work immediately #505

[stuartmscott]

Yeah that is a big issue, hadn't noticed it before but now I can reliably reproduce on Catalina. Whatever code MacOS runs to activate an app after switching to it from another isn't getting run on initial app startup. But I'm just guessing - I don't have much experience as an Apple developer, I was going to start learning and port some Android apps over, but then I got into Go and found this cool cross-platform UI library :)

I used to be all about Java and "Write Once, Run Anywhere", a decade later the platforms, languages, runtimes, and libraries are all different but the goal remains (unfortunately so does the anti-goal "Write Once, Debug Everywhere")

[toaster]

AFAICS this is fixed on the GLFW master (but unfortunately not on the 3.3 branch).
So we probably have to wait for the 3.4 release and after that for the adoption by go-gl :(.

[stuartmscott]

Okay, thanks for the update @toaster. I'm not familar with GLFW's release process, when is 3.4 expected?

[toaster]

I have no idea. But I found a fix for our issue. Might be that the fix in GLFW wouldn’t even helped us.