Aerial: Aerial 3.34 crashing legacyScreensSaver - Sonoma 14.1

  • Mac model: Mac Mini 2020 M1
  • macOS version: 14.1 (23B74)
  • Monitor: (1) DELL S2721QS via HDMI port

Since about the last week or so (that I noticed) my screensaver has been crashing/hanging. When this happens, only a blank black screen is shown instead of the videos when the screensaver activates.

Checking activity monitor reveals the legacyScreenSaver process is hanging and eating 100% of the CPU.

image

I have to force-quit that to get things working again. Is anyone else experiencing this or have any ideas on how to troubleshoot it further?

Attached below are a spindump and a process sample.

About this issue

  • Original URL
  • State: closed
  • Created 8 months ago
  • Comments: 34

Most upvoted comments

Hey @Nicholas-Westby

First thanks a lot for chiming in with your example.

I’ll try to give a few pointers below and a general understanding of what’s wrong in Sonoma to cause this. But I would highly highly highly recommend you file a bug with feedback assistant on your Mac to Apple with your simple example (and hopefully some info I give below can give you a better understanding of the errors you see).

FYI, my guess is this is a very general problem unrelated to this codebase, perhaps having to do with macOS changes.

Yep this is my understanding too. We have some mitigations but it’s not effective for everyone it seems. You’ve noticed two separate things that I believe are linked :

When I dismiss the screensaver and attempt to view it again, I get a black screen (perhaps because it’s already busy on the old screensaver that won’t quit).

So this is what people call the black screen bug most of the time, somehow, you get black screens. Some people talk about getting it progressively if they have multiple monitors, one screen starts acting up, then another, then another, see here : https://github.com/JohnCoates/Aerial/issues/1359

The second issue is the crashing that you describe

Here’s a zip file you can use to reproduce:

Swirloids.zip

I Googled the error I saw in activity monitor and landed on this GitHub issue and thought I’d add some extra context.

Here’s what I see in my activity monitor:

activity-monitor

Do you reproduce 100% the crash or is it once in a while ? My understanding is that it happens only some of the time, and most of the time you get the first issue (still there but black screen). Can you confirm ?

So the big question, why does this happen ?

Screensavers are plugins, as in, a class that gets loaded, then instantiated for each screen, by some part of macOS. Because of security risks, Apple started adding a layer between ScreenSaverEngine.app (which used to load screensavers) and 3rd party screensavers. It’s called legacyScreenSaver.appex, it’s an app extension, and the root of all issues for the last 5 years with screensavers 😃

With Sonoma, things got a lot worse though, as they changed how screen savers and wallpaper works in a very very convoluted way. There’s a thread somewhere with our findings on this but long story short, a casualty of all this is that legacyScreenSaver hangs around when you exit the screensaver by yourself (it doesn’t I believe if your mac goes to sleep, but will if you start the saver and interrupt it before your mac goes to sleep).

This is not how things used to work. legacyScreenSaver used to exit gracefully, thus killing us, a few seconds after you exited the screensaver and went back to the desktop. But now it doesn’t. Moreover, it keeps our instances around (one per screen), and will keep piling up new ones everytime you start the screensaver (you can log this easily if you are curious). At best this brings a huge memory leak.

Because our class is instantiated by the system, we have little say in all this and can’t deinstantiate ourselves. We did find “one weird trick” where we can force our parent process to exit. It’s certainly a bit naughty, but it works 99.9% of the time and avoids both bugs :

  • legacyScreenSaver doesn’t have time to crash
  • since we recycle it we avoid the instance stacking and everything that comes with it.

Still, for some, it still crashes, so that trick is imperfect.

Another solution I had was using Aerial’s Companion app to look for legacyScreenSaver (wallpaper) and kill it from the Companion after you get back to desktop. I never pursued this because, annoyingly, the wallpaper word gets localised. Maybe this is just a superficial thing in Activity Monitor but I never tried to look it up more.

Maybe it could act as a second line of defence as, most of the time, if you force quit it, things go back to normal. But again, for some people, sometimes macOS freaks out about something somewhere, and only a reboot fixes it (yay).

So yeah, long story short, it’s massively annoying.

If you want to give a try to the same mitigation we came up with, look at the AerialView.swift class and look for 2 functions called onSleepNote and willStop. They are linked to some system events that we hook to in the function just above (see the notification code for both that you will also need).

Another thing I notice is that it paints the first frame, but then just gets stuck there. It should be painting an updated time every second, but the time never changes.

So I don’t use animateOneFrame but my best recollection is that this has not worked for years.

You need to listen to startAnimation and stopAnimation and do your thing from there.

Again, feel free to ask (maybe create a separate issue) if you have questions about screensavers, but please please please report your bug with your sample to Apple, as this can only help to get more reports on this.

@glouel

No the file is 175MB and appears intact. I was able to open it with QuickTime Player and play it through entirely.

image