0.4.11 crashes on macOS whenever finger moves on touchpad.

[bumfo]

0.4.10 works fine.

0.4.11:

The following error is reported:

-[__NSArrayM unsignedIntegerValue]: unrecognized selector sent to instance 0x6000008c0150

On some run, it reports the above error constantly. On some run, it crashes a few seconds after you move your mouse inside the window.

[bumfo]

Below is the only log when it crashes (Java 17 on Ventura 13.1):

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000018dd25820, pid=4412, tid=259
#
# JRE version: Java(TM) SE Runtime Environment (17.0.4+11) (build 17.0.4+11-LTS-179)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0.4+11-LTS-179, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# C  [libobjc.A.dylib+0x9820]  objc_msgSend+0x20
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

[bumfo]

This is the stack trace in hs_error_xxx.log

Current thread (0x0000000153811000):  JavaThread "main" [_thread_in_native, id=259, stack(0x000000016b150000,0x000000016b94c000)]

Stack: [0x000000016b150000,0x000000016b94c000],  sp=0x000000016b9477a0,  free space=8157k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libobjc.A.dylib+0x9820]  objc_msgSend+0x20
C  [AppKit+0x167348]  -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:]+0x1050
C  [AppKit+0x166124]  -[NSWindow(NSEventRouting) sendEvent:]+0x11c
C  [AppKit+0x6ddfc4]  routeGestureEvent+0x12c
C  [AppKit+0x165178]  -[NSApplication(NSEvent) sendEvent:]+0x69c
C  [libjwm_arm64.dylib+0x8b50]  -[JWMNSApplication sendEvent:]+0x64
C  [AppKit+0x3b7360]  -[NSApplication _handleEvent:]+0x3c
C  [AppKit+0x2ca08]  -[NSApplication run]+0x1f4
C  [libjwm_arm64.dylib+0x8d14]  -[JWMApplicationDelegate runLoop]+0x140
C  [Foundation+0x4cd30]  -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:]+0x344
C  [Foundation+0x4c844]  -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:]+0x70
C  [libjwm_arm64.dylib+0x7a70]  Java_io_github_humbleui_jwm_App__1nStart+0x7c
j  io.github.humbleui.jwm.App._nStart(Ljava/lang/Runnable;)V+0
j  io.github.humbleui.jwm.App.start(Ljava/lang/Runnable;)V+17
j  xxx.Demo.main([Ljava/lang/String;)V+5
v  ~StubRoutines::call_stub
V  [libjvm.dylib+0x462ef8]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x38c
V  [libjvm.dylib+0x4c4b30]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)+0x12c
V  [libjvm.dylib+0x4c7f84]  jni_CallStaticVoidMethod+0x118
C  [libjli.dylib+0x5378]  JavaMain+0x9d4
C  [libjli.dylib+0x7958]  __JVMInit_block_invoke+0x50
C  [Foundation+0x400f0]  __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__+0x18
C  [Foundation+0x3ffb0]  -[NSBlockOperation main]+0x68
C  [Foundation+0x3ff40]  __NSOPERATION_IS_INVOKING_MAIN__+0x10
C  [Foundation+0x3f358]  -[NSOperation start]+0x2c4
C  [Foundation+0x79b30]  __NSThreadPerformPerform+0x108
C  [CoreFoundation+0x81a18]  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__+0x1c
C  [CoreFoundation+0x819ac]  __CFRunLoopDoSource0+0xb0
C  [CoreFoundation+0x8171c]  __CFRunLoopDoSources0+0xf4
C  [CoreFoundation+0x80320]  __CFRunLoopRun+0x344
C  [CoreFoundation+0x7f888]  CFRunLoopRunSpecific+0x264
C  [libjli.dylib+0x6fec]  CreateExecutionEnvironment+0x190
C  [libjli.dylib+0x31fc]  JLI_Launch+0x4a0
C  [java+0x3bac]  main+0x190
C  [dyld+0x5e50]  start+0x9f0

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  io.github.humbleui.jwm.App._nStart(Ljava/lang/Runnable;)V+0
j  io.github.humbleui.jwm.App.start(Ljava/lang/Runnable;)V+17
j  xxx.Demo.main([Ljava/lang/String;)V+5
v  ~StubRoutines::call_stub

[bumfo]

Seems like this is solved on newest master, can be closed once a new version is released ;)

[tonsky]

0.4.12 should be handling that