Hammerspoon: Hammerspoon Exits or Crashes above 0.9.75

[maxsnts]

Hello

Both in OSX 10.13 and the latest 10.15, all versions above 0.9.75 exists by itself of crashes.
I don't know hot to help more than this other than to say that the behaviour is erratic.

I only notice when some hotkeys stop working, then when i place the mouse hover the hammerspoon icon, it goes away.

Is there any way i can see any info that would help?

Thanks

[latenitefilms]

Can you find any Hammerspoon crash logs in the below folder?

~/Library/Logs/DiagnosticReports

[maxsnts]

Hi
I deleted those as i did not know if they were the result of my lua script.
I installed the latest version, and will be using it until i get a report.

Thanks

[maxsnts]

Hello, here is the top part of one log
Hope it helps.

Process: Hammerspoon [56629]
Path: /Applications/Hammerspoon.app/Contents/MacOS/Hammerspoon
Identifier: org.hammerspoon.Hammerspoon
Version: 0.9.78 (5164)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Hammerspoon [56629]
User ID: 501

Date/Time: 2020-03-27 15:54:43.423 +0000
OS Version: Mac OS X 10.13.6 (17G5019)
Report Version: 12
Anonymous UUID: 17BD3328-A214-ABBF-9561-B27B7448CA8F

Sleep/Wake UUID: 8F8BFE45-3200-4E95-8708-D4EDCE9C9101

Time Awake Since Boot: 310000 seconds
Time Since Wake: 19000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000018
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

VM Regions Near 0x18:
-->
__TEXT 0000000107783000-00000001078a3000 [ 1152K] r-x/r-x SM=COW
# [/Applications/Hammerspoon.app/Contents/MacOS/Hammerspoon]

Application Specific Information:
objc_msgSend() selector name: isProxy

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fff6b093e9d objc_msgSend + 29
1 libsystem_trace.dylib 0x00007fff6bfee4fe _os_log_fmt_flatten_data + 134
2 libsystem_trace.dylib 0x00007fff6bff4282 _os_log_impl_flatten_and_send + 1602
3 libsystem_trace.dylib 0x00007fff6bff6502 _os_log_with_args_impl + 449
4 com.apple.CoreFoundation 0x00007fff43d447cf _CFLogvEx3 + 239
5 com.apple.CoreFoundation 0x00007fff43d2dee1 CFLog + 161
6 com.apple.CoreFoundation 0x00007fff43d174c6 _CFBundleLoadExecutableAndReturnError + 710
7 com.apple.CoreFoundation 0x00007fff43d4f2b0 CFBundleGetFunctionPointerForName + 48
8 internal.so 0x000000010ae74453 caffeinate_lockScreen + 166
9 org.hammerspoon.LuaSkin 0x0000000107ac3024 luaD_precall + 681
10 org.hammerspoon.LuaSkin 0x0000000107abf1d4 luaV_execute + 708
11 org.hammerspoon.LuaSkin 0x0000000107ac3192 luaD_call + 64
12 org.hammerspoon.LuaSkin 0x0000000107ac31d3 luaD_callnoyield + 21
13 org.hammerspoon.LuaSkin 0x0000000107aaefd2 luai_objcttry + 28
14 org.hammerspoon.LuaSkin 0x0000000107ac36d0 luaD_pcall + 110
15 org.hammerspoon.LuaSkin 0x0000000107abce20 lua_pcallk + 236
16 org.hammerspoon.LuaSkin 0x0000000107aa5a18 -[LuaSkin protectedCallAndTraceback:nresults:] + 203
17 org.hammerspoon.LuaSkin 0x0000000107aa5acd -[LuaSkin protectedCallAndError:nargs:nresults:] + 55
18 internal.so 0x000000010adb55b1 trigger_hotkey_callback + 298
19 internal.so 0x000000010adb5895 hotkey_callback + 181
20 com.apple.HIToolbox 0x00007fff42fa4904 DispatchEventToHandlers(EventTargetRec, OpaqueEventRef, HandlerCallRec) + 1541
21 com.apple.HIToolbox 0x00007fff42fa3c4d SendEventToEventTargetInternal(OpaqueEventRef, OpaqueEventTargetRef, HandlerCallRec) + 374
22 com.apple.HIToolbox 0x00007fff42fb8f21 SendEventToEventTarget + 39
23 com.apple.AppKit 0x00007fff41a0ff94 -[NSApplication(NSEvent) sendEvent:] + 1788
24 com.apple.AppKit 0x00007fff412708b5 -[NSApplication run] + 812
25 com.apple.AppKit 0x00007fff4123fa72 NSApplicationMain + 804
26 libdyld.dylib 0x00007fff6bcb8015 start + 1

Thread 1:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0x00007fff6bdff20a mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff6bdfe724 mach_msg + 60
2 com.apple.CoreFoundation 0x00007fff43cecea5 __CFRunLoopServiceMachPort + 341
3 com.apple.CoreFoundation 0x00007fff43cec1f7 __CFRunLoopRun + 1783
4 com.apple.CoreFoundation 0x00007fff43ceb867 CFRunLoopRunSpecific + 487
5 com.apple.AppKit 0x00007fff413b8fc4 _NSEventThread + 184
6 libsystem_pthread.dylib 0x00007fff6bfd0661 _pthread_body + 340
7 libsystem_pthread.dylib 0x00007fff6bfd050d _pthread_start + 377
8 libsystem_pthread.dylib 0x00007fff6bfcfbf9 thread_start + 13

Thread 2:
0 libsystem_kernel.dylib 0x00007fff6be0928a __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x00007fff6bfd020e _pthread_wqthread + 1552
2 libsystem_pthread.dylib 0x00007fff6bfcfbe9 start_wqthread + 13

Thread 3:
0 libsystem_pthread.dylib 0x00007fff6bfcfbdc start_wqthread + 0
1 ??? 0x7265666572504643 0 + 8243107278867154499

Thread 4:
0 libsystem_pthread.dylib 0x00007fff6bfcfbdc start_wqthread + 0

Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x947ed6ccee7e0004 rbx: 0x0000000000000004 rcx: 0x00007ffee847a4c8 rdx: 0x00000000000003f8
rdi: 0x00007fa1c0445690 rsi: 0x00007fff41f0afb3 rbp: 0x00007ffee847a410 rsp: 0x00007ffee847a348
r8: 0x00007ffee847a4e0 r9: 0x00000000000003f8 r10: 0x0000000000000000 r11: 0x00007fff41f0afb3
r12: 0x00007ffee847adc2 r13: 0x00007ffee847b6e2 r14: 0x00007fff43c6a001 r15: 0x00007ffee847a4e0
rip: 0x00007fff6b093e9d rfl: 0x0000000000010246 cr2: 0x0000000000000018

Logical CPU: 0
Error Code: 0x00000004
Trap Number: 14

[latenitefilms]

Any ideas @asmagill ?

[cmsj]

The crash is happening on line 261 of https://github.com/Hammerspoon/hammerspoon/blob/master/extensions/caffeinate/internal.m#L249

The address being 0x18 is interesting, that somewhat suggests that loginFramework might be NULL, and we don’t actually check if that’s the case or not.

I can’t explain why it’s not finding the login.framework - yes we’re digging around in private API, but it should work fine even on a machine with SIP enabled.

It might be interesting to check if /System/Library/PrivateFrameworks/login.framework is damaged somehow, perhaps by running sha1 against it in a terminal and comparing with other machines, but I think at the moment the best we can do would be to guard against loginFramework being NULL so we at least don’t crash.

In terms of getting you back up and running again, remove any calls to hs.caffeinate.lockScreen() and you should be ok.

[asmagill]

I'm wondering if it has to do with whether or not Hammerspoon has full disk access? While we probably should verify loginFramework even after loading it and bail with an error or warning if it's still NULL, I suspect he'd be seeing other issues if the framework was actually corrupt.

I do see that Hamemrspoon has full disk access in my Security & Privacy settings, but I'm not sure when I was asked for this, so not sure if there is a way we can trigger it specifically or not.

[maxsnts]

To be honest, i appreciate your suggestions but i think something else is going on.
I agree that it makes sense to be something about the login framework since it seeams to get worst when i use that, especially since it was changed to lock instead of switch user.
But it happens in 3 machines, different OS. So i would rule out corruption.
It also works fine after load, so i would rule out access.
It crashed randomly.
I will comment out the lock feature, update to the last version and see.
Do you think all thing caffeine should be comment out or only the lock?
(I use cafeine quite a lot)
Thank you

[asmagill]

@cmsj, I think this is the problem at https://github.com/Hammerspoon/hammerspoon/blob/master/extensions/caffeinate/internal.m#L304-L306

We release it during a reload, but we don't set it to NULL... this prevents the framework from being reloaded so after a reload of Hammerspoon, it depends entirely upon whether or not the system has gotten around to collecting the now released item or not.

The fix is to either not release loginFramework or add loginFramework = NULL ; after the release.

Personally I favor the setting it to NULL -- I like it when everything is reset so a reload is as close to the real thing as possible, but in this case, either should work.

If no one submits a pull I'll try to this evening when I get a chance.

[latenitefilms]

On Catalina, try giving Hammerspoon full disc access in the “Security & Privacy” section of “System Preferences” and see if that fixes things.

The most recent Catalina release seems to be even more restrictive and locked down than previous releases. I haven’t tested personally to confirm, but I believe you can no longer access “~/Library/Application Support” based on some error logs I’ve seen for CommandPost.

@asmagill - A feature to detect full disk access permissions would be very handy.

Related: https://github.com/MacPaw/PermissionsKit

[maxsnts]

@asmagill It makes sense. The "random" nature of GC could account for the lack of pattern on the crash.

[cmsj]

Thanks @asmagill :)