Updated app won't run because Sparkle.framework is missing

[fabulouspanda]

The file works fine if it's downloaded from the website directly…

Could this be due to having switched my development environment to 10.9 and thus having to add a run script to compile the app with Sparkle included?

[fabulouspanda]

Actually, the bug seems to randomly occur and can go away if you just try opening the app again, and occurs whether downloaded directly or through sparkle, but the crashes lead back to sparkle framework.

This is the build script I'm using with it:
LOCATION="${BUILT_PRODUCTS_DIR}"/"${FRAMEWORKS_FOLDER_PATH}"
IDENTITY="Developer ID Application: my name(my code)"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/Sparkle.framework/Versions/A"

[KenThomases]

What error message are you getting, exactly? There's probably a crash report. Show that.

[fabulouspanda]

Sometimes it complains that Sparkle.framework is missing and sometimes it gives a more general exception fully captured here:
https://alpha.spacemonkey.com/shares/pAfWOOKmk90YfwGG3zA2YA/macminer_crashreport.txt

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: aString != nil'
terminating with uncaught exception of type NSException
abort() called

I'm using 1.5b6

[KenThomases]

Sounds like two separate issues. Show a crash report from when it complains that Sparkle.framework is missing.

Regarding the crash report you linked: you're evidently calling -setStringValue: on a control (or assigning to someControl.stringValue) and you're passing a nil pointer rather than a valid string. Have you symbolicated the MacMiner + 77199 frame? You should look at whatever line that is. Unless the string pointer was obtained from Sparkle, that probably has nothing to do with it. (Even if it was, it's your responsibility to check that it's not nil before passing it to -[NSControl setStringValue:].)

[fabulouspanda]

Dyld Error Message:
  Library not loaded: @loader_path/../Frameworks/Sparkle.framework/Versions/A/Sparkle
  Referenced from: /Applications/MacMiner.app/Contents/MacOS/MacMiner
  Reason: image not found

I'll double check for sloppy string assignment…

[KenThomases]

So that says that there's no binary at /Applications/MacMiner.app/Contents/Frameworks/Sparkle.framework/Versions/A/Sparkle. You originally said that "[t]he file works fine if it's downloaded from the website directly". Is that downloaded from the same URL that your feed specifies?

Also, are any of the folders within your app bundle marked as read-only (lacking the write permission)? I've seen problems where the various folder copying APIs fail in that case. They create the subdirectory and then dutifully set its permissions to read-only to match the source. They then try to copy in the contents but fail because it's read-only.

[fabulouspanda]

It’s the same file - either way, updated or direct download there’s a chance of this crash. Re-downloading (and I suspect trying to open the app a second time) allow the app to open. Nothing is marked as read-only and I’ve been building the app in a very similar manner for half a year.

I’m hoping that somehow a string setting problem is causing this false report of a missing framework… just applied an update with an extra safety in place so I’ll see whether it helps things!

On 13 Dec 2013, at 11:03, KenThomases [email protected] wrote:

So that says that there's no binary at /Applications/MacMiner.app/Contents/Frameworks/Sparkle.framework/Versions/A/Sparkle. You originally said that "[t]he file works fine if it's downloaded from the website directly". Is that downloaded from the same URL that your feed specifies?

Also, are any of the folders within your app bundle marked as read-only (lacking the write permission)? I've seen problems where the various folder copying APIs fail in that case. They create the subdirectory and then dutifully set its permissions to read-only to match the source. They then try to copy in the contents but fail because it's read-only.

—
Reply to this email directly or view it on GitHub.

[KenThomases]

I can't imagine the crash report is false. It's coming from dyld, the dynamic loader. It's happening during the loading of your app, before any of its code has had a chance to run, so there's very little opportunity for it to be due to a bug in the app code.

Could it be that the copy operation is still in progress when the app is being launched?

[psulak]

I wanted to chime in here and say that some of our customers are having the same problem (some or all of the Sparkle framework is missing after Sparkle downloads the new app, unzips it, moves it into place, and relaunches it). We've seen it randomly in earlier versions of the OS, but it seems to be happening more with our 10.9 customers. However, I'm beginning to suspect this isn't a bug with Sparkle, but rather with OS X. Here's why:

1. Our app includes several frameworks (Sparkle, FeedbackReporter, and XMLRPC). After a Sparkle update, sometimes the Sparkle framework is missing. Other times, it's FeedbackReporter or XMLRPC.
2. Our app also uses PFMoveApplication (https://github.com/potionfactory/LetsMove/) to let users move the app to the Applications folder at first launch. Sometimes the Sparkle framework is missing after PFMoveApplication has done its work.
3. The problem of the missing Sparkle framework doesn't just happen at unzip time -- I can get it to happen when zipping the app. I've observed this is on my 10.9 dev Mac running Xcode 5.0.2. After I compile a new build of our app, sometimes doing a Finder right-click to compress the app results in a missing Sparkle framework in the compressed archive. If instead of doing a right-click compress in the Finder I use Terminal and do a "ditto -c -k --rsrc --sequesterRsrc --keepParent", the resulting zip is always complete.

So we're definitely seeing this problem as well, but given the above I'm beginning to suspect that the issue isn't with Sparkle but rather something in the Finder or the file system. I've spent hours scouring the net for anyone else having these problems, and so far this is about the only thread I've found that matches the problems we're seeing. I haven't tried filing Radar yet (mainly because I can't reproduce the problem with any certainty and Radar always seems like a black hole anyway). But I gotta think that there's more than just one or two developers having this problem, right?

phil

[KenThomases]

@psulak: When checking the archive, are you using the built-in Archive Utility to uncompress the archive or do you have a third-party unarchiving tool? We've seen problems with third-party tools failing on valid archives, leaving files missing or truncated.

[fabulouspanda]

I ran in to the bug once personally and it was with Archive Utility on a VM close to a standard system install but as you say it's hard to reproduce, so most of my information comes from app users.

[psulak]

Ken,

Typically to check the archive I do two things:

1. I do a Get Info and look at the file size. If it's below a certain threshold then I know something's wrong
2. As a backup I move or copy the zip to the Desktop, double-click to unzip the app, and then use Xcode's FileMerge to diff the resulting app against the original.

I've occasionally used zipinfo in the Terminal, but that's a bit of a pain:-)

I'm trying to get into the habit of using ditto in the Terminal to compress the app, but usually I'm too lazy to fire up the Terminal. If I use right-click in Finder, then I'll typically compress the original app at least twice. The first zip is the one that's sometimes too small. The second zip is usually the correct size.

[tomandersen]

Just had this exact thing happen. I 'as usual' zipped the app and uploaded the zip file. Comparing the zips:
The 'bad one' is 1,124,057 bytes, while doing the exact same command again in the Finder results in a zip that is 1,299,372 bytes, so like 150k bigger. I wonder if the Archive process - and export signed app that I use is slow - it was not done doing the signed export from Xcode when I zipped the app up the first time.

That scenario is more likely IMHO than the Finder doing archives 'wrong' sometimes.

[psulak]

Hey Everyone -

FWIW, we switched from ZIP to TGZ files for our Sparkle updates. The problem of the app missing files after Sparkle downloads and decompresses the update has been reduced significantly. It still happens from time to time, but the problem isn't nearly as bad as when we were using ZIP files for our updates. YMMV.

[psulak]

@tomandersen, I don't think time is a factor with the Finder Zip bug (as I now call it). In my experience, I can wait 1 minute, 5 minutes, 10 minutes, etc after Xcode completes its build before right-clicking to ZIP the application, and it just doesn't matter. The first Zip file is always bad, and the second is fine. BTW, I opened a Radar with Apple about this bug. I've been able to verify that the bug isn't being caused by either my fusion drive, or apps such as Dropbox (which do code injections into the Finder). If any of y'all are able to reproduce the Finder Zip bug, please open Radars as well.

[psulak]

Quick update: I'm unable to reproduce the Finder Zip bug in 10.9.2. Please note that is on the archiving side of things and not on Sparkle's side (unarchiving). As far as unarchiving goes, we've been using TGZ files for several weeks now, and although the missing frameworks problem is greatly reduced, it still occurs from time to time.

[kornelski]

For most of the apps it should be safe to link Sparkle.framework as Optional, so when OS X can't find/load it the app will still run, it just won't be able to update. So for now I suggest doing that as a workaround/fail-safety.

I've also created #345 to explore what can be done when Sparkle fails to load.

[fernandomorgan]

Sparkle as optional is a double edge, right? the auto update is one of the most important features to get right, so that you can fix (other) issues.
If it's mandatory, the bug (missing framework) is easier to detect :)

[kornelski]

Yes, very good point. Please have a look at issue #345 and see if that approach can be improved.

[danielchasehooper]

@pornel Has any progress been made on this? I'm seeing it on first launch of an app with Sparkle 1.8. Any idea which version introduced this so that I can get the version before it?

[kornelski]

@danielchasehooper nothing has changed in that area recently. Please file a bug with more information, especially console output.

[danielchasehooper]

@pornel Fixed my own problem: the framework was in the copy bundle resources phase rather than a custom "frameworks" copy files phase