App can crash if relaunched manually during update installation

[jspahrsummers]

It's unclear the exact set of circumstances that can cause this, but relaunching the parent application too quickly (i.e., when update installation has begun but not completed) can result in crashes from trying to load incorrect nibs, and probably other resources too.

We could maybe fix this by having Squirrel automatically abort installation if it notices that the application has started again.

[mdiep]

Alternatively, should we toggle the executable bit during installation? If the installation has begun, you're probably still in the danger zone.

[jspahrsummers]

Installation of the new bundle should be atomic (in the sense that there's never an incomplete or inconsistent bundle in place), so I'm not super clear on where the exact failure is here. My guess is that there's some kind of race condition in the OS itself that finds the main bundle after the executable has actually been loaded, resulting in a mismatch between resources and the running code.

I'd like to avoid putting the app bundle into any kind of invalid state, because installation can always fail for unknown reasons (power loss, crash, etc.), and the app should remain usable if that happens. There's already a tiny window where it can go missing, and that freaks me the fuck out, even with all of our recovery strategies.

[harryi3t]

@jspahrsummers

there's already a tiny window where it can go missing

Does it depend on the size of the App? Our App is around 300 MB and it takes around 16-30 seconds when I am using SSD for the updated App to start launching. I am guessing this number would be much higher for hard disk drives.

Did you find any workaround to avoid this?

[jspahrsummers]

@harryi3t This thread is more than five years old. I'm afraid I don't have the context here anymore.

[aprilandjan]

I'm facing the exact same problem described here, and I believe the bundle size and bundle file counts matters

[rickymohk]

Facing this issue in 2023 when using electron. To reproduce the issue:

1. Launch the app, wait for update download complete
2. Quit the app to proceed update
3. Launch the app again immediately, before the update complete. This will bring up the non-updated version
4. Close the app window (not quit)
5. When the update complete, open the app (as the app was not quit, the app process is still the old version, but the old app's Resources are already gone) , the OS will say "The app is damaged and can't be opened. You should move it to the Bin"
6. Once you move it to the bin, you will get the same error whenever reinstalling the app from dmg, until you reboot the machine.

So the problem is since macOS separates "process" and "window", you can have the app bundle being updated by squirrel while the old process is still alive without opened window. Then when you attempt to open window from the old process, it screws up. The OS thinks the app is damaged, though you can still recover it before moving it to Bin by right click the app in the applications folder and select open. But if you do move it to Bin, somehow it won't let you install the app again until reboot (tested in macOS 13.3.1)