macOS 10.13.4 Freezing with BetterTouchTool Usage

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!

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.

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.

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

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.

Froze again - emailed a couple of log files.

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.

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.

@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.

Just came here to say: "Me too". Let me know if I can somehow help debugging this.

For me this happens pretty accurately after BTT was running for about a day. Killing BTT immediately solves it. I then can start BTT for another day before the problem occurs again.

Since this is happening about after a day for me... this also happens to be in the late afternoon / evening. Thinking about what I'm doing around that time, the only thing that comes to my mind is having a video conference via Zoom app (https://zoom.us/)

As described earlier, everything freezes whenever the window focus changes. What I have not read here so far: It also freezes for me, when I activate the search box in the activity monitor. That's the only search box that does that though. Search boxes in other apps don't have that effect. Also interesting: Opening Spotlight Search per ⌘+Space does not cause a freeze. That is the only focus change that does not trigger the problem. I doubt it, but maybe this detail can help solve the issue.

The last time the problem occurred, I was sitting in the backyard and had no USB or BT devices attached. Only power. So I'm kinda sure it is not related to USB. :slight_smile:

Can you maybe find a common app that all of you have installed?

Looking at the details from the posts above, here is what I have in common:

  • Bartender 3
  • iStat Menus
  • Magnet (Sorry. I know BTT can do this and I even bought BetterSnapTool but I somehow like this better :smile: )
  • iTerm 2
  • 1Password

Next time it freezes (probably Monday afternoon/evening CET) I'll try first killing all these apps and see if that helps.

Though I'm sure it is not related to iStat Menus and Bartender. When the freezes began I spend a good while killing all apps and I remember those were among the first - without solving the problem.

Versions etc:

BTT 2.530
macOS 10.13.5 (17F77)
MacBookPro13,3 (15", 2016, w/ Touch bar, Intel Core i7, 2,7 GHz)

For completeness, my first problem description on GitHub: https://github.com/folivoraAI/BetterTouchTool/issues/1032#issuecomment-399466628

Cheers,
Daniel

Thinking about this... one of the major differences here is, that an app change does modify the menu bar content, a window change within the same app does not.

Also opening spotlight search per ⌘+Space does not modify the menu bar.

Not sure how my observation with the search box in activity monitor fits into that theory - that does not change the menu bar content.

If in fact it is related to changes of menu bar content, then the likeliest conflicting app seems to be Bartender. https://www.macbartender.com/

Oh, interesting. Until now it seemed that use of USB input devices was a common factor.

EDIT: actually, I'd think that even in a laptop the interal keyboard and touchpad are still attached to the USB bus? So it could still be related to input devices I guess. Although as I and others have reported, it's not only an input freeze - screen refreshes often stop for me as well.

Now you mention it, I have a similar finding: I don't use Spotlight because I use Alfred 3. But like you found, opening Alfred search (which I also do with ⌘-Space) does not trigger a freeze.

As per my edit in my previous post, I can confirm the AM search bar also causes a freeze for me.

Yeah good point - menu bar switch does seem a common factor in all occasions except the AM search bar. Probably that AM search bar means the menu bar isn't a factor, but it's worth testing.

I have just had my latest occurrence, 3 days, 16 hours and 20 minutes after I rebooted to install an OS update (to 10.13.6 B5). As per my edit to my previous post, this happened when I opened Alfred 3's preferences window. Nothing to do with Path Finder this time, so those previous occurrences were likely a coincidence.

I have now closed Bartender, then restarted BTT to clear the issue. So if Bartender is a factor, I will know in.. 3 to 5 days :slight_smile:

Interesting how many of us seem to have fairly predictable intervals, but they're all different. Yours are ~24 hours. Mine were originally around 96 hours, then I had a 120 hours followed by 88 hours.

I don't use Bartender on either Mac, and the problem occurs. The Retina Macbook 2017 with latest HS has no peripherals, and only Microsoft/Adobe/Apple stable software installed. And BTT. That should rule out a conflict with exotic apps or peripherals.

There's more to this. It's a past experience: I hadn't yet associated the problem with BTT. Because the computer was extremely slow to use, I did not try quitting BTT or do much troubleshooting at the time of the observation. I just used a keyboard shortcut to reboot the Mac. So, I haven't tried that method yet. It may work! I will try it if the problem happens again. Today I found this thread, applied the terminal spell, and started using BTT again after a 2 day break.

The log message can be seen with Console.app. Filter for "kernel" in the all-inclusive log after the problem happens. After that, with every stutter, you should see a matching "kernel stalling" message whenever the stutter begins. For me the freeze repeats, when I try to interact with the computer with a mouse/trackpad, and an accompanying Console message appears at the same time. They're gone after reboot.

CPU spikes may not be the cause, it's just correlation. The computer could idle on for 24 hours without a hiccup, but after I started working, within a few hours there was a freeze or two, every workday. That's been the case for the past few weeks. Time will tell if the terminal defaults command helps. If I get more freezes, I'll capture the debug log.

Perfectly on time my system was freezing at 5:20pm CET - while I was on video conference per Zoom.us.

Again, only power is connected. No external USB devices and no BT devices connected.

I'm also seeing the "stalling for detach from IOHIDSystem" on every freeze and CPU usage spike of +20%. Usually my system is not using more than 15% to 20% even when Zoom is running.

I killed all of the applications listed in my previous post per activity monitor and nothing had an effect on the freeze. Only killing BTT solves it.

We can also rule out the change of menu bar content. While some interactions with icons in the menu bar cause no freeze, others do. For instance, I'm using Fluid.app to show an JIRA overlay on the desktop and this does not change the menu bar content - but freezes the system.

I'm leaving BTT turned off now. As said, let me know if I can help debug this any further. Also, since this happens for me very reliably around the same time of the day, I can offer you to do a live screen sharing session via Zoom so you can search logs in console yourself etc while it's happening.

Cheers,
Daniel

Interesting. There must be some correlation there, something in a video conference call that triggers it, or increases the likelihood of triggering it. Perhaps related to use of the webcam and/or microphone? An extra device in use? (I assume an internal webcam is on the USB bus, though the microphone probably isn't.)

I've not yet had another occurrence - I'm not due another one for at least 24 hours, on my usual schedule. When I do I'll check the Kernel stalling message. Presumably I'll see it as well.

Regarding those CPU spikes - that may well be tailspind and/or spindump, rather than the freeze directly causing a spike of its own. I noticed that the first time it happened - I had Activity Monitor's CPU chart open and every time a freeze occurred, I briefly saw tailspind or spindump hit the top of the CPU %. Whatever app I was switching to or from would be noticed by the OS as freezing, so it profiles them with tailspin/spindump and that generates a CPU hit.

I'm sure @Andreas_Hegenberg is debugging this and will find something soon. Luckily for me it's only every 3-4 days so I don't have to give up using BTT, I'll just deal with restarting it periodically. I have so many gestures configured I'd be lost without it!

FWIW, I run Zoom a lot, and most of my BTT hangs are when Zoom isn't running.

Just happened, much sooner than expected. 2 days 14 hours from the previous occasion. This time it was when I clicked away from Microsoft Remote Desktop onto a different tab in Firefox - so both switching to Firefox and changing the visible tab.

I can confirm that I too have the "stalling for detach from IOHIDSystem" messages in Console.

This time seemed a bit more severe, in that the freezes also caused the audio to stop in a playing video, and seemed to last a bit longer than the ~15 seconds I measured previously.

Luckily BTT can be configured with a shortcut to restart itself. I've made that to be control-command-option-backspace. I just hit that when the freeze happens. Not an optimal situation, but it's an easy to use workaround to continue using BTT.

I got another freeze yesterday, even after the terminal spell had been applied for days. Forgot to catch the logs though, sorry.

thanks for the logs everybody, I'm now pretty sure about the change in 10.13.4 that's causing this and will release an update soon.

I'm currently on our honeymoon, mostly without internet, so it will probably not be available until end of next week unfortunately.

2 Likes