Restarting macOS apps automatically on crash | Hacker News Reader

Restarting macOS apps automatically on crash

notes.alinpanaitiu.com

36 pointsalin2352 comments

Great comments everyone! Really nice hearing from all these devs experienced with writing crash free apps that never crash with inscrutable tracebacks which after days of investigation turn out to be caused by a DisplayLink driver.

It’s refreshing to see your users never angrily contact you to fix crashes you can’t fix and that your only answer is not “sorry you will have to just relaunch the app”

Your unfounded assumptions are a delight, indeed I must be doing something wrong and maybe just didn’t put in the work into fixing these errors, and after 6 years of developing the same app and looking at the Sentry dashboard every day and talking to users through email/Discord/Twitter/Reddit/forums and looking at their video recordings and deciphering their explanations and sending them betas and custom utilities that definitely reproduce how the crash is not a user error… sorry, what was I saying?

God damn it man, it’s this thing every day here.

I just wanted to share a readily made solution for people that are in desperate need of it and have exhausted all other possibilities. I’m not trying to make everyone create crash loops and bringing systems to a grind.

One should be careful about what they put in a signal handler. Doing complex things like calling into Foundation, especially in a signal handler that indicates something has really gone wrong, is probably not a good idea.

I came here for this. Signal handlers have to do only async-signal-safe things.

I expecting to see logic to detect crash loops. What happens then?

Exactly, I wouldn't be comfortable just blindly auto-restarting an app after a crash. macOS offers a “Relaunch” button in these situations, so you can restart it interactively. That's good enough for me.

I don’t suggest this.

Your application may crash due to:

- hangs / spins - memory corruption - programmer error / faulty logic (think loooping infinitely) - thermals / memory usage

Let launchd handle restarting your application by allowing the user a “Relaunch” button

Or maybe you've been signed up for free fuzzing by your local government security service. Restarting the app so they can continue probing is only courteous.

Prob take longer to get out of a crash loop than to just cdm-space and type first 2 letters of the app name and enter.

The developers of Kindle for Mac might want to read this

Reminds my how Basecamp use to restart their Rails app 400 times/day.

https://dhh.dk/posts/31-myth-2-rails-is-expected-to-crash-40...

> Bonus: restart on hang

This is not good for battery life. I'm not sure how to heuristically detect hangs in a power-friendly way.

"My software crashes so often that it's worth the time to automate restarting it" is what I'd expect of a windows user. Has macOS really gotten that bad over the last few years? I remember being forced to use it a long time ago and while it was very limited and special, nothing ever crashed or was visibly buggy.

100% of crashes on my M1 MBA occur in applications when accessing files over SMB network shares. One every couple of days. I have to restart about once every week or two because it borks the system completely.

But when I'm not connected to an SMB drive, I don't think I've had a single crash in years.

I have no idea if it's something in the SMB driver itself that's crashing, or assumptions inside of application logic that fail in certain SMB scenarios.

SMB really is hell. I write business software and our admins do what they can to avoid using it because it's very hard to know when it fails.

But from a dev perspective, that's probably a driver level issue because that's where you want to handle or propagate errors instead of crashing.

It’s faulty app logic, assuming an io error cannot occur accessing a filesystem. They’ll also crash if you have disk issues or driver problems. The important thing is they may not even realize they’re calling into a function or routine that can access the fs for something!

All io access needs to be recoverable or catchable for your app not to crash. You’d be surprised how much background fs activity there can be in apps (or indirectly triggered by apps!) all the time.

That and sandboxing effects with perhaps improperly accessed bookmark data

I'm building a macos app now, and only because I wasn't catching fs access error did I realize I needed to handle folder access carefully when using bookmarks in core data.

I swear _Finder_ has this bug if you plug in a superannuated external HDD.

This is one reason where I think Rust shines, and has even improved how I write C++.

So many areas where rust makes me deal with a result or option that are easy to take for granted. It’s a strong reminder of the number of things we should be treating as possible error cases

It makes you do something, but if the consumer just does .unwrap() the end result is going to be the same.

Sure, but a developer can also write any number of other code that’s irresponsible. At that point the language has done all it can for them, and the onus is on the developer to not be lazy.

And when the crash happens, it’s obvious why

Stuff like this with NFS was my living nightmare for years. On Linux it would put processes into the D state and you'd have to restart the entire machine to fix anything.

Why is the assumption the OS is the fault and not the app doing something it shouldn't be doing so the system slaps it? If the OS was at fault, would not the OS be crashing rather than the app. To me, it sounds like the OS is working nicely with a misbehaving app.

Maybe the better question would be if the OS SDK is to a state that doing naughty things is easier to do, but again, that's not the OS

>"My software crashes so often that it's worth the time to automate restarting it" is what I'd expect of a windows user.

This is insulting even for windows users.

That's why I flagged it.

Yes, but it’s also funny, and not mean-spirited or targeted at a specific person. Windows users are in no way a protected class.

No, it's just targeting a specific group of people with false facts, while not being remotely funny, unless your choice of humor revolves around shitting on users for their OS choice, aka petty tribalism.

Humor is more complex to get right, it needs some punchline or an arc within the context where your initial expectations are subverted, in order to be funny, not just "windows users are like X".

Hold up there, joke police. Petty tribalism is actually funny. It’s gross tribalism which goes too far.

Listen to Garrison Keillor’s old radio shows, and amidst the long story arcs are little tribalist jokes between the Christian denominations (and Unitarians?), and among the different peoples of Scandanavia. Like this one, the jokes rely on the implicit context inflating the difference between people on the basis of tribalism. And being a part of the subculture, the audience all knows this.

The same is true in sports comedy, and sports is nothing if not petty tribalism. And while you may not actually have to be a masochist to be a Mets fan… wait, bad example. Anyways exaggerated differences based on self-assigned fandoms is how this all works. Just like operating systems.

An OS is a tool, not a sports team. And that supposed joke was not funny no matter how you try to slice it.

It's as funny as calling Mac users Sheeple.

I hate to break it to you, but I think you don’t have a good sense of humor. This is fine, everyone is different and that’s okay.

Minor teasing is a part of the theory of humor, as proposed by Immanuel Kant. I don’t purport to go all the way on superiority theory, but insult comedy is a part of comedy nonetheless. I personally dislike it but I do recognize it as humor.

Incidentally regarding the part of my previous comment that’s a joke: the joke is not the insult. The joke is a surprise theory one, that I was going to make a statement about sports, but at the last minute I reversed by pretending the example was true. The butt of the joke is myself, talking myself out of a coherent point.

Of course by analyzing it you ruin it for most people, but there we are.

You do realize that what you personally defined as "humor and teasing" against a broad userbase is against HN guidelines, right, which is why it got flagged?

Also, something being humorous requires it to be funny and get people laugh, but I don't think many are laughing as making fun of Windows users jokes have been stale since the days of Windows Vista, Mac VS PC ads were the rage, and Steve Jobs still had a pulse.

If that canned joke still makes you laugh in 2023, maybe your sense of humor is bad.

MacOS applications are just like applications on any other platform. Why the juvenile Windows bashing?

No they're not, otherwise we'd use those other platforms.

I use Windows.

I also use Windows... for gaming once a week, because it provides a passable experience using my crap PC hardware. I use a mac for everything else because it lets me get work done without being distracted by how poorly text is rendered, how dated some of the icons and interfaces are, or by the fear that I'll need to re-install the operating system once in a while. For me, my Windows pc is my Chromebook with a gpu, for others, it's their primary.

Which OS do you use? It sounds like it can't be Linux! Looking forward to hearing about this crash-free nirvana.

The only app that has been crashing or freeze, on my Fedora box these last few years is a Microsoft app: Edge.

Arch. My PC sometimes hangs for no reason, which it also did with windows. It used to be a non-issue because it was too loud to run it overnight, but now it's quiet so I'm trying to figure that out. Every nvidia driver update has about a 10% chance to break something. That was also the case on windows so I just didn't update it there and had great success with recommending people to find a version that works and never touching it again.

I don't recall ever having an issue that was fixed by restarting an application though. If it doesn't work, I read the error message to figure out why it doesn't work and fix that. No "just try again, it might work this time" like on windows, which I enjoy.

If you don't know why the app is crashing, then you don't know enough to blame the OS or the ecosystem. That's true of any operating system. Apps aren't magically crash free because they're on a Mac. Dereferencing an invalid pointer can still segfault you just as quickly.

I’m not going to get into the Mac vs Windows flamewar but I worked at a place with this infuriating attitude about crashes. Our (desktop) application crashed so much that customers were complaining. Instead of, you know, fixing the crashes, the tech lead declared that we would instead build a “launcher” app that just sat in the background and restarted the application every time it crashed. Horrible “crashes are inevitable and hard to fix!” attitude. Talk about a morale killer.

solution looking for a problem

I'm not really a fan of auto-restart on crash. In some cases, it could cause damage.

I consider a crash -any crash, to be my fault. This includes things like yanking out the power cord (which probably will just stop the program counter, as opposed to careening off into the weeds).

No matter how abusive the user is, no matter how out-of-band their behavior, my software should never crash.

I love crashes. They tend to be easy to fix (of course, thread collisions are another matter). If I can reliably reproduce a crash, I can usually fix it in a few minutes.

In iOS, Apple makes it impossible to quit an app. I have heard of developers deliberately forcing a crash to do that, but, if Apple catches you doing it, they'll yank the app. They won't approve apps they can get to crash. In fact, they have, in the past, found crashes that I missed.

Just better off, writing software that can handle always-on, and that doesn't crash.

Crashes are often the result of the platform behaving in unexpected ways, not users.

Back in the mists of time when writing cross platform software for any platform (Mac, Win < 95, SunOS + xview) each platform had bugs and we’d have to take pains to workaround them. Our customers didn’t care whose fault it was.

It used to be that a single tech support call cost us any profit from 3 copies of the product.

Things are different now though - the frameworks on platforms have orders of magnitude more surface and complexity. And most small companies don’t offer 1-1 support anymore.

In my experience, crashes are usually my error.

Swift helps a lot. It has a lot of safety in it. I haven’t had a memory leak in ages.

Also, Xcode has gotten really good at letting me know when I have a future crash.

Memory leaks aren’t unsafe fwiw.

They often result in eventual crashes (but relatively controlled ones), and can affect performance.

So “unsafe” is relative.

In any case, memory leaks are sloppy, and I have a personal aversion to writing sloppy code.

Crashes are not unsafe either.

This is true, everything is sandboxed, these days (but I'm not as sure about MacOS, as I am about iOS).

But it's still a bad look, and Apple won't approve an app, if they can get it to crash -regardless of the reason.

That comes back around to whether the user or the platform is the reason for the crash. If a user puts in something weird then it’s your job to fix that, almost always.

I’ll be a bit pedantic and say, that even by the Swift (or rust) language:

1. Crashes aren’t unsafe. They’re actually preferable for both Swift and rust than getting into an unsafe state with incorrect data. So in that sense, crashes are the seen as safe, just undesirable as an outcome.

2. Memory leaks can’t be unsafe any more than a badly optimized algorithm.

But yes, they’re sloppy and should be avoided. I just contend that there’s no real case where I think they should be considered unsafe from the model of a programming language.

They might be unsafe from the model of a context specific use. E.g you wouldn’t want a memory leak locking up your system in vehicular automation. But I’d fall back to it just being sloppy programming if that state is achieved.

Failing to account for platform behaviors can be your fault, but it doesn’t mean you can account for them at all times. If you put something in user defaults and cfprefsd crashes at that moment, you might lose a value you stored: should your code handle that? Probably not. In this case you could say “well I could try again, or check to make sure I really saved the data” but can you really? Are you going to write an exponential backoff algorithm to raise your confidence of consistency for each setting you write? Much less for all the other things that can break? Sometimes the appropriate thing to do is get the crash log that the GPU failed and if they ask you about it you read and tell them what happened.

Good point.

Reply on news.ycombinator.com