Crash: Hard crash on macOS
haudan opened this issue ยท 2 comments
This issue is likely related to #89. I'm opening this ticket anyway for more context. Feel free to consolidate.
Looks like the offending code is a callback registered with glfwSetJoystickCallback, or maybe the function call itself.
After further trial and error, it appears this has to do with macOS' input monitoring access control. When MidnightControls attempts to read game controller input, the player is prompted with a "allow input monitoring" prompt, or something similar. Until this prompt has been confirmed, the game immediately crashes. It's unclear whether this is a problem with MidnightControls or possibly GLFW. Once the prompt has been confirmed, the game doesn't crash anymore and the mod is able to read controller input just fine (after mapping).
Describe the bug
- When Minecraft is already running and a controller is being connected, the game crashes in-game.
- When Minecraft is started with a controller already connected, the game crashes on startup.
- Removing MidnightControls from the mod directory, the game does not crash in any way.
To Reproduce
Steps to reproduce the behavior:
See above. Tested with an Xbox Elite Wireless Controller Series 2 over Bluetooth.
Expected behavior
Not crashing.
Screenshots
Desktop (please complete the following information):
- OS: macOS Ventura 13.3.1 (M2 Pro).
- Minecraft 1.19.4
- Fabric loader 0.14.19-1.19.4, Fabric API 0.77.0+1.19.4
- Mods: too many to list.
- Version 1.8.1
- Branch 1.19.4 (presumably)
Additional context
Excerpts from the crash log (it's quite long):
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00000001952eaa28, pid=58936, tid=259
#
# JRE version: OpenJDK Runtime Environment Microsoft-33154 (17.0.3+7) (build 17.0.3+7-LTS)
# Java VM: OpenJDK 64-Bit Server VM Microsoft-33154 (17.0.3+7-LTS, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# C [CoreFoundation+0x1fa28] CFArrayGetCount+0x8
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# https://github.com/microsoft/openjdk/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Time: Sun Apr 16 23:35:57 2023 CEST elapsed time: 7.638930 seconds (0d 0h 0m 7s)
--------------- T H R E A D ---------------
Current thread (0x000000014b810c00): JavaThread "Render thread" [_thread_in_native, id=259, stack(0x000000016ecdc000,0x000000016f4d8000)]
Stack: [0x000000016ecdc000,0x000000016f4d8000], sp=0x000000016f4d0e70, free space=8147k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [CoreFoundation+0x1fa28] CFArrayGetCount+0x8
C [IOKit+0x48d7c] __IOHIDManagerDeviceApplier+0x250
C [CoreFoundation+0x48bcc] __CFSetApplyFunction_block_invoke+0x1c
C [CoreFoundation+0x489e4] CFBasicHashApply+0x94
C [CoreFoundation+0x48928] CFSetApplyFunction+0x140
C [IOKit+0x4914c] __IOHIDManagerInitialEnumCallback+0x78
C [CoreFoundation+0x7f710] __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__+0x1c
C [CoreFoundation+0x7f6a4] __CFRunLoopDoSource0+0xb0
C [CoreFoundation+0x7f414] __CFRunLoopDoSources0+0xf4
C [CoreFoundation+0x7e01c] __CFRunLoopRun+0x33c
C [CoreFoundation+0x7d58c] CFRunLoopRunSpecific+0x264
C [libglfw.dylib+0x10450]
C [libglfw.dylib+0x8ab8]
J 13494 org.lwjgl.system.JNI.invokePP(JJ)J (0 bytes) @ 0x000000010e3fc5c8 [0x000000010e3fc540+0x0000000000000088]
C 0x000000016915252e
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 13494 org.lwjgl.system.JNI.invokePP(JJ)J (0 bytes) @ 0x000000010e3fc5c8 [0x000000010e3fc540+0x0000000000000088]
j org.lwjgl.glfw.GLFW.nglfwSetJoystickCallback(J)J+6
j org.lwjgl.glfw.GLFW.glfwSetJoystickCallback(Lorg/lwjgl/glfw/GLFWJoystickCallbackI;)Lorg/lwjgl/glfw/GLFWJoystickCallback;+4
j eu.midnightdust.midnightcontrols.client.MidnightControlsClient.onMcInit(Lnet/minecraft/class_310;)V+95
j net.minecraft.class_310.handler$cfd005$midnightcontrols$onInit(Lorg/spongepowered/asm/mixin/injection/callback/CallbackInfo;)V+4
j net.minecraft.class_310.<init>(Lnet/minecraft/class_542;)V+2538
j net.minecraft.client.main.Main.main([Ljava/lang/String;)V+1342
j java.lang.invoke.LambdaForm$DMH+0x0000000800325400.invokeStaticInit(Ljava/lang/Object;Ljava/lang/Object;)V+10 [email protected]
j java.lang.invoke.LambdaForm$MH+0x0000000800325800.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V+19 [email protected]
j net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(Ljava/lang/ClassLoader;)V+74
j net.fabricmc.loader.impl.launch.knot.Knot.launch([Ljava/lang/String;Lnet/fabricmc/api/EnvType;)V+40
j net.fabricmc.loader.impl.launch.knot.KnotClient.main([Ljava/lang/String;)V+4
v ~StubRoutines::call_stub
siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x0000000000000000
Update: it's a problem with GLFW itself. Compiling and running a simple hello-world with GLFW produces an identical crash. My Minecraft log file also mentions segmentation fault, possibly from a null pointer. GLFW version tested 3.3.8.
I'll try and raise this with the GLFW devs. GLFW issue here: glfw/glfw#2320
Update: The bug has been fixed in upstream GLFW. Commit: 2c1d310.