Alt-Tab started more instances of itself

[nfekete]

Describe the bug

I discovered I'm running three instances of AltTab at the same time. Normally, if one instance of AltTab is already running, you cannot start another one, it activates the currently running one instead when you try to start a new one. I'm not sure how this happened, but I guess AltTab started two more instances of itself.
With three running instances, they are all triggered by the trigger keyboard shortcut, so I need to do three selections to dismiss all the AltTab popups.

Screenshots / video

» ps ax|grep AltTab

97689   ??  S      0:47.20 /Applications/AltTab.app/Contents/MacOS/AltTab
97694   ??  S      0:39.39 /Applications/AltTab.app/Contents/MacOS/AltTab
97702   ??  S      0:48.23 /Applications/AltTab.app/Contents/MacOS/AltTab

Steps to reproduce the bug
I don't know how to reproduce the issue, it only happened once using version 6.13.0. I've been running 6.13.0 since about it's release.

[lwouis]

Hi @nfekete!

I can't reproduce the issue locally.

I have implemented the macOS API so that if the app is launched when it's already running, it shows the preferences window of the running app. This is for people who hide the menubar icon. This way there is still a UX to open the preferences window.

There was also an issue in the past where AltTab would start as a login item right after the user logs in their session. I made sure there that there can't be multiple AltTab.

There was also a potential issue where someone could have various versions of AltTab that they downloaded to test them at some point. Each would add their own login item, and multiple would thus launch after login.

All these edge-cases have been handled. Furthermore, on your ps output, we see that it's the same location/binary.

Oh, I found another edge-case: if you remove a required permission like Accessibility Permission in System Preferences, AltTab notices it, and restarts itself. The goal is to restart, run the launch sequence, realize the permission is missing, and show the user the window explaining that the permission is required to work.

That restart code use macOS open -n tool. The idea is that for a safer restart, it's better to first start a new instance, then quit the current one. The code used to be just open + quit, and I thought it could lead to some data-races were the launch would happen while the app is still open, and trigger the preferences panel instead.

I've spent a bunch of time looking online at how other people restart their app, and it's surprisingly a very complex problem. I didn't want to add a supervisor process that handles the restart because it's way more complexity to handle, so I used this open -n approach. I guess something went wrong in your case. I can't picture how the code would result in 3 instances though. The next line after open -n is to quit the current app. So even in a weird scenario, the app would quickly spawn and die, spawn and die, etc. How can it stay running after spawning the new instance?

Any hypothesis, steps to reproduce, etc are welcome. As it stands I don't know what to do next.

[nfekete]

I'm using AltTab since Jul 15 2020, and this only happened a single time, today, about 3 weeks into using 6.13.0, so my guess would be that it's indeed related to the restart code which was changed in commit 56d47fc

Not sure if it's good news or bad news, but seemingly there are only two lines to analyze. :)

Unfortunately, I am not familiar at all with MacOS development. Still, if any of those two lines could fail (i.e. break the execution flow between starting another instance and exiting the current one), that could explain this behavior.

If we assume that the restart method doesn't fail in the first line, since it successfully start a new instance of AltTab, my guess would be that the second line somehow fails to stop the currently running app.

Looking at App.shared signature, that should never return a null value, so – if the previous assumptions are correct – most likely it's the NsApplication.terminate(_ sender: Any?) that fails to stop the currently running instance. Looking at the documentation of that method, it seems like a lot of things will be going on until the app will indeed stop, with multiple opportunities for the terminate sequence to be cancelled. My gut feeling is that something happens while that method is executing that prevents AltTab from successfully exiting.

On termination, the applicationWillTerminate should be invoked by the termination sequence, but seemingly it's not, since the shortcuts seem to be still active (note that in my bug description I mentioned that all three running instances of AltTab are triggered by my hotkey, Cmd+Tab, since I have to dismiss them all to get back to my application window). So either the termination sequence fails somewhere before invoking applicationWillTerminate, or applicationWillTerminate itself is failing the termination sequence.

These are just some random tips that came to my mind by a first glance to the AltTab code. It might be something entirely different.

[lwouis]

it's indeed related to the restart code

Why would that code trigger for you though? I assume you didn't remove the System permissions for AltTab, right?

Furthermore, you say you're on 6.13.0, which is where I fixed the heuristic to detect the Screen Sharing permission which used to have false positives. So I would expect AltTab to not have any false positives anymore, and only restart if you actually remove permissions.

Regarding the termination process, yes we call terminate which means the system calls the app on applicationWillTerminate where we free the native command-tab (in case the user binded alt-tab to command-tab in the preferences). It's a private API call that's very hacky, yet I don't expect any issue here like the call blocking. In any case you say the 3 apps are interactive, so we are not in that code path, but instead are running the main loop.

[nfekete]

I don't know what is triggering restart, if indeed that is what is happening here, but I didn't fiddle with permissions at that time, or any time lately.

I don't expect any issue here like the call blocking

I don't think it's blocking either.

[nfekete]

Today something interesting happened. Macbook was resuming from standby, and as soon as I unlocked the machine — while it was still in the usual slow process of recovering from sleep —, I tried to switch apps with my shortcut, Cmd+Tab. Alt-tab appeared with the missing permissions screen, then, after a short while, it disappeared. The next time I pressed Cmd+Tab, the usual AltTab grid with the windows appeared.

(Note that this is not a screenshot of the actual popup I've got, I'm not sure which of those two permissions were missing, maybe both).
I did not end up running multiple instances of AltTab this time.

[lwouis]

Mmm it may be that the new heuristic to detect Screen Sharing Permission reports false negatives during wake-up?

i can't really reproduce/debut that, unfortunately. And the heuristic i use is the best i know of. I don't know what could be done here.

Maybe run the heuristic like 3 times over 3 attempts, and if the results keep being negative, only then restart the app?

[nfekete]

I don't know. Since we're lacking info on what is exactly happening, I would wait with changing anything in the code.

Does AltTab do any kind of logging? If yes, maybe you could add some logging to around these events (missing permissions, restart of AltTab) so that it can be collected later. Without that it's going to be difficult to move further with the issue since it's so hard to reproduce it.

[lwouis]

The permission check is a single API call. I searched online and on Github, but there seem to be no report of issues with CGDisplayStream.

The only thing I can imagine is that sometimes, for a very brief period of time, for instance when the computer wakes from sleep, or maybe when the user just plugs/unplugs an external display, that method may return nil.

This would then need to happen exactly when AltTab checks for permission (every 5s).

So again, the only thing I can imagine to work around that issue would be to add a counter, and only restart after 2 or 3 checks. That way we avoid these flukes. The downside being that we delay quitting AltTab further. I think it's reasonable.

You mentioned logs. There is no logging for now, unfortunately. I couldn't find a good way to log across all macOS versions we support, and that's easy to use from the dev perspective. Furthermore, in our case, I can't imagine what we could log that would be useful. We know the function returned nil, and this is why the app restarted. Now why macOS returns nil when we ask to capture the screen, and the user has granted permission? That's a blackbox we can only work around.

[nfekete]

Now, what you're saying rings a bell to me. I'm using my MacBook with an external display, keyboard and mouse. Driving two displays makes the MacBook produce more heat and it runs the fans at higher RPM with more noise as a result, which I find annoying. I usually close the lid of the MacBook as a result of this. This time, when this bug happened, in order to wake up the MacBook, I opened the lid, pressed on the fingerprint button, and closed it pretty much right away. So there was a lot of display configuration change for the OS to process, while at the same time doing the recovery from sleep. Maybe it's related to the display change and not the wakeup itself, or a combination of these two.

[nfekete]

I managed to reproduce the issue, again, by Cmd+Tab-ing right after waking up from sleep with display changes. The popup looked like in the screenshot above, so only the Screen Recording permission was missing.

[lwouis]

Great, it means the workaround I'm adding will most likely avoid it. This temporary messy state of screens readjusting shouldn't persist for 10s straight.

That being said, my workaround only affects the first issue of restarting AltTab. Once it restarts, it's still unclear why instances can sometimes multiply like mushrooms.

[lwouis]

@nfekete have you witnessed this issue since we last spoke? I'm wondering if I should keep this ticket open, or if we can consider it solved.

[nfekete]

I did not experience it again for a while now. I'm on 6.19.0 currently.

[lwouis]

Wonderful! I'm closing this ticket. Please let me know if you experience it again 👍

[juicetin]

Hi, I've been experiencing this recently (seems to happen on every restart without fail, on the latest version at the time of this comment, 6.31.1). Are there any logs/anything I can upload to give you more visibility of why it may be happening? Thanks!

[lwouis]

@juicetin you most likely have multiple versions of AltTab installed. Please look in your Downloads folder and your whole harddrive. If you only have 1 version installed I expect it will not happe

[zeljkomarinkovic]

This happens to me as well just like @nfekete described. With several instances (5,6,7) of AltTab running at same time and it only happens after putting my mac to a longer sleep (over night for example). Currently on 6.46.1

[zeljkomarinkovic]

Now with proof :)

[lwouis]

@zeljkomarinkovic what's the parent process of these instances? Launchd?

[zeljkomarinkovic]

i have killed all instances but here is current

edit:
Happened again today, after updating to 6.47 and all processes are same as in img above also noticed that it happens when Alt-Tab freezes and i get pop up same as @nfekete and it probably want to start again and starts multiple instances

[zeljkomarinkovic]

With last update it happens a lot more than usual

[lwouis]

Investigations on this issue are continuing here: #1840. The current suspect is this runningboardd process starting multiple instances of AltTab. It's a process from Apple, and no-one understands really why it instanciates new instances of AltTab. I think we will be able to fix this once we get more data, and some insights into what this process is doing and why.

[TransRapid]

Please reopen this. This issue still happens. I also wonder, for everyone else who is also having this issue, are you using the option to reopen windows when logging back in? I have that on mine, but I am not sure if it will happen if that is not checked, haven't tried just yet. OS X Ventura 13.4.1 (22F82).

[lwouis]

@TransRapid please read my message just above yours.

[TransRapid]

Thanks, misread that, I will jump to the other thread there.