macOS 10.13.4 Freezing with BetterTouchTool Usage

Bug Reports
20

One question: after restarting BTT, does it work again for a few hours or do you need to restart your Mac then?

I can see a long timeout when BTT is checking which gestures/shortcuts should be activated for the given app, but BTT isn't doing anything special at this point :-/ (just some database lookups).
If you can reproduce this again, it would be awesome if you could create a sample of BTT using this terminal command (hit enter then switch the window):

sample BetterTouchTool -file ~/Desktop/BetterTouchToolSample.txt
21

Restarting BTT is sufficient to resolve the freezes. I'm pretty sure it happens after a few hours again regardless of rebooting the Mac.

Furthermore, the lags seem to me to be somewhat IO related. For example it also freezes when switching detail view in Tunnelblick, which loads log files into text view.

I did not apply the fix yet, but when I was prompted for a system password while BTT was freezing my system, the freezing was more intensive if that makes any sense. Like it even froze when accepting input for the password dialog, other apps just freeze when switching the active window.

22

@Andreas_Hegenberg

Sampled the samples: stack-samples.zip (68.7 KB)

BTT started to do the freeze bug again, I switched to iTerm and invoked the command. Then I switched to another window, which triggered the freeze. Nothing too crazy in the stack though :confused:

23

For me restarting BTT causes everything to be fine for days. It was about 4 days between incidents one and two, and another four days between two and three. In both cases my workstation was on 24/7 with no sleep in-between, with BTT running continously until the freeze issue forced a restart (of BTT only.)

So it could be related to some kind of leak, something that only happens after a period of continuous running? Or it could be a coincidence that it's been approximately 96 hours between each of my occurrences.

I've now run the Secure Input disable, so if I'm still running OK after a few more days, that might say something.

I updated to 2.530 yesterday, right after my third occurrence of the problem. I won't now restart or update again for a while, and will see if it happens again or not.

24

I'm seeing a similar issue.

macos 10.13.5, with BTT 2.530 (happened with the previous BTT release as well). I'll email the BetterTouchToolDebug dir to you shortly.

I'm using an external keyboard (MS Sculpt with it's own USB dongle) and an older Apple bluetooth trackpad. After a few hours-days of running BTT, my input devices stop working for seconds at a time: typing on the builtin macbook keyboard, typing on the the builtin keyboard, moving/clicking the external trackpad, and moving/clicking the internal trackpad are all completely ignored. This lasts for 5-60 seconds or so, then I can type/trackpad for a few seconds, and then the input devices are ignored again.

It does not appear to affect anything else running on the system: it's happened during a video call (with Zoom) and the audio/video continued working fine, and my Activity Monitor window continues to update regularly.

It's as if the input devices are turned off, and then on for a bit, and then off, and then on again... forever until I quit BTT. As soon as I quit BTT the input devices work again.

Thanks for BTT, and for helping to track this down! I'll try the 'sample' command the next time it happens.

-svec

25

So far the logs I received seem to indicate this terminal command should help: (run while BTT is quit completely)

defaults write com.hegenberg.BetterTouchTool BTTDisableSecureInputLookup YES
28

today just happen again, bug report was sended to andreas@folivora.ai

29

My btt always pops the window that need the api, I set up and it worked ,but when I slept my computer ,then the btt wont work and pops the window again ,why ? and the api auth can not be edited,why? mac os mojave 10.14 beta pls help me

30

@TsienJX these are bugs in the mojave beta, which apple will need to fix.

31

Update: I applied the SecureInputLookup disable fix at:
2018-06-27 22:55
It is now:
2018-07-02 11:17

And no fourth occurrence of the problem has yet happened. That's a gap of around 109 hours (with no system sleep, system restart or BTT restart in-between), which I believe is the longest I've gone between occurrences since the issue first occurred.

Therefore it seems hopeful that BTTDisableSecureInputLookup has fixed the problem.

I'll report back if it does happen again at any point.

32

I got the input device hang again, even with "com.hegenberg.BetterTouchTool BTTDisableSecureInputLookup" = YES.

(I had restarted BTT after setting that to YES.)

This hang was slightly different than before though: before setting com.hegenberg.BetterTouchTool BTTDisableSecureInputLookup to YES, once the input devices started being ignored, they would seemingly randomly work and then stop working again. Switching applications (while the input devices worked) would not trigger the input devices to stop working again.

Now, with com.hegenberg.BetterTouchTool BTTDisableSecureInputLookup set to YES, once the input devices stop working, they start working randomly, but as soon as I switch applications then the input devices immediately stop working for a little while.

I've emailed 2 'sample' command outputs as the input devices transition from working to not working - hope those help!

Thanks!

33

Did you apply it with BTT closed? Or did you apply it with BTT open, then re-start BTT?

What you said here seems to imply the latter, and that might not work - Andreas said BTT must be closed before the defaults command is applied.

34

I applied it with BTT closed - sorry I wasn't clear in my earlier post. I made sure to quit BTT before applying it, and then restarted BTT - that was before my most recent hang.

35

Ah OK, fair enough. Maybe I will have the issue re-occur too at some point then :frowning:

36

Yup, happened at 03/07/2018 01:20 - approx 122 hours after the last ocurrence. That's an extra 24+ hours between occurrences compared to the previous 3 intervals, so maybe SecureInputDisable at least reduced the frequency? But too few data points to be sure.

Some further details:
A. When the issue happens for me, it affects screen refreshes as well - not only input devices. But the duration of the screen refresh impact is variable.

In order to test this I opened top in an iTerm 2 window, set to 0 second refresh, then triggered the issue with the usual method of switching windows. Sometimes after I switched a window, both input and screen froze at the same time. But on other occasions, the screen kept updating for a few seconds before it froze. For example:

  • Test 1: Screen & input both freeze for a total of ~15 seconds;
  • Test 2: Input freezes for 15 seconds; screen is frozen only for 8 of those seconds (seconds 8-15.)

After a few tests it seemed about 50/50 as to whether the screen freeze would last the same as input (as per Test 1) or be a shorter duration (Test 2). But in all cases there was at least some screen freeze.

In all tests the total freeze time was consistent at around 15 seconds, give or take the accuracy of my stopwatch measurement

B. I mentioned that the last time it happened that there was a correlation with Path Finder. This has seemingly happened again.

I have switched to and from Path Finder dozens of times in the last 5 days with no issue. Just now I switched to Path Finder, then launched a video file from it (double-clicked on an MKV file on an SMB network share, causing VLC to launch to play that video.) As soon as I double clicked, everything froze, and it took ~15 seconds for VLC to appear and the video to start playing. From that moment onward, I had the freeze on any app switch until BTT was restarted.

So in this instance, it was switching out from Path Finder to a newly opened app (VLC) that first triggered the issue. The previous instance, it happened when I switched to Path Finder from either Firefox or RealVNC (can't remember.)

No idea if that's at all helpful in diagnosing the issue. Will keep posting findings if anything else occurs.

37

Froze again - emailed a couple of log files.

38

Same issue here. Seems to be related to overheating. When my iMac runs hot and CPU is spiking, the freezes start for upto 30 seconds or so each time.

39

Same issue. Happens after a few hours of working, usually during intensive periods, which corroborates that this could be related to CPU spikes. I've documented the issue here: https://forums.macrumors.com/threads/kernel-stalling-for-detach-from-iohidsystem.2122152/

The problem is associated with a system log message: "Kernel stalling for detach from iohidsystem" that appears exactly when the freeze starts. And the freezes don't go away without a reboot.

I've had this since latest High Sierra and latest Mojave, on two Macs. BetterTouchTool has been off (not running) for two days now, and I haven't had the issue in these two days. I'm using both Magic Trackpad and Magic Mouse. The latest High Sierra installation is almost vanilla, out of the box with no Time Machine restore, yet the problem happens. BTT is the most "exotic" tool of that setup.

40

@petterihiisila - do these "Kernel stalling" error messages appear in /var/log/system.log?

If so, I don't have occurrences of that error message (or any mention of 'stalling' or 'iohid') over the past week, during which I've had the freezing issue at least twice.

I have monitored /var/log/system.log during freezes (only after they started though) and couldn't spot any message that seemed to correlate with them.

But I've not yet looked into the Console - perhaps that's where this error appears?

Also, you say that for you it only resolves with a reboot? That's definitely different to me and I think others in this thread, as for us it resolves by restarting BTT. In my case, it doesn't re-occur for four or five days after each restart of BTT.

I've not noticed any obvious correlation with CPU load or temperature. I can't yet work out what causes the issue to first start, but once it has started it will occur every time I switch application (by any means), but only on application switch. I definitely don't think I have a temperature correlation, because the last two occurrences have been late at night when general temps were much lower than they had been hours earlier. CPU usage is a possibility - the most recent occurrence started when I launched a video file from Path Finder, thus causing VLC to open, so that would have involved some activity. Though certainly nothing unusual compared to day-to-day usage. And the time before I am pretty sure I was just switching between two already-open apps, with no obvious CPU activity occurring at all. So I can't say I'm noticing an obvious CPU or temp spike associated with the start of freezing.

So your symptoms seem a little different to what I've seen so far. Presumably the same problem but presenting differently (and more severely for you, it seems, if you have to reboot.)

EDIT: I can no longe rreply to this thread because of some three-post limit for "new users". I've emailed Andreas to ask this to be removed. In the meantime I can only edit past posts. EDIT 2 : thanks Andreas, limit is now removed.

I will add here that I've just had my latest occurrence. It has happened three days, 16 hours and 20 minutes after I restarted (to install an OS update, to 10.13.6 B5). It was triggered by opening the Alfred 3 preferences window. So this time there was no correlation with Path Finder - so that was probably coincidence on previous occasions.

I can also confirm, that like @Daniel_Schroeder discovered in the next post, the issue occurs when I click on the Activity Monitor search bar. That's the only time I've noticed it happened within the same application. Maybe AM's search bar does something different to other search bars, something that makes it similar to an app switch?

One more tiny piece of info: I notice that keyboard input is not lost during the freeze. Ie if I keep typing during the freeze, all characters typed appear at the end of the freeze.

Anyway I'll post more when the 3-post limit is removed.