Crashes that seem to be related to Sparkle

Dear Andy.
Thank you for your answer. Great to hear that this problem is fixed in the current version.

Cheers!
Markus

Thanks Andy Matuschak, that solved my question.

Andy,

What if I'm still seeing problems like this one and @loader_path is being used? It's sporadic we get reports like this but consistent enough that we've had to start looking into it. Most of my users are reporting that it happens immediately upon startup after updating (as I would kind of expect).

Process: QuicKeys [511]
Path: /Applications/QuicKeys.app/Contents/MacOS/QuicKeys
Identifier: com.quickeys.quickeys
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: launchd [425]

Date/Time: 2009-06-01 10:35:40.320 -0400
OS Version: Mac OS X 10.5.7 (9J61)
Report Version: 6
Anonymous UUID: 39193C70-0143-4681-B7B3-0E8FA5726262

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread: 0

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

I'm totally at a loss. I haven't heard about this from any other apps; is there anything unique or weird about the way yours works? Any custom behavior?

Is it possible that this user somehow updated to a copy of the app without Sparkle.framework?

No, nothing unique or custom, although we've just recently added prefixes to all the classes in Sparkle to help alleviate the namespace collision issue.

There is no chance the user updated to a version without Sparkle or even to one with a different version. We've included 1.5b6 in every beta and full release made public. It could be that the download is getting corrupted somehow but I don't see how that's happening either. It's almost like the framework isn't present in the app bundle after we unzip but only Sparkle, never any of the other frameworks we use.

And when the user downloads a new copy from our site (the same .zip we have Sparkle pull) and reinstalls, the problem is always resolved.

Hm. Do you sign your updates? (If so, that guards against corruption). And it's a .zip, right?

Could you send me a copy of your app at <email address hidden>?

It happens to me as well in Querious (araelium.com). This only started happening since I updated from Sparkle 1.1 to 1.5b6. I sign my updates, it's a zip, and I can confirm the zip is correctly formed. I've had at least five users report this problem, and I'm guessing there are more that encountered it. If they download the same zip file and open it themselves it works fine.

Does your app do anything interesting or prolonged on shutdown?

My thoughts on this and similar mystery bugs is that Sparkle just really needs to not install the new version until the old version is actually closed. Which means moving installation into the command-line tool. For 2.0.

Nope. Nothing funny. I implement applicationShouldTerminate: and do some checks, but once the app has decided to terminate, it just does it immediately. So far all reports are when launching X86-64, though that's pretty much expected these days. They also all had SUAutomaticallyUpdate, SUCheckAtStartup, and SUEnableAutomaticChecks set to YES

Sorry to add fuel to the fire, but I'm having this same problem. It never really occurred to me that it might have something to do with Sparkle - I thought it was something dodgy in my own app but I've moved any startup logic out of applicationDidFinishLaunching, so basically my app now sits and does NOTHING when it launches, and yet it still crashes intermittently.

I can post a crash log if you want, but including the Binary Images section, it's 160 lines long so is there a better place to send it? For what it's worth, I've seen this crash on x86 as well as my own G5 (PPC 64), so I don't think it's solely restricted to X86-64.

I have also seen it occurring during an Xcode build and run, so I'm not convinced it's related to a corrupted download/install. One of my users also said he could avoid the crash by removing my app's preferences, but that it would always come back after a few days.

Mark

Hm, interesting. And you're using 1.5b6, or HEAD?

Would you throw the log up on http://gist.github.com or something?

Yes, I'm using 1.5b6. I have posted one of the logs at http://gist.github.com/177999 but looking more closely at the logs from the others above, I now think it's not the same crash at all as I'm not getting the "Dyld Error" message in the crash logs.

Sorry for wasting your time.

Hm. We've fixed a bunch of non-main thread messaging and a few dangling pointers since 1.5b6. I wonder if that's gone away?

/me sighs. Still crashing for users.

Andy: What changed between 1.1 and 1.5 for installing? 1.1 works fine, so I'm guessing it's some subtle side effect of a change.

Sorry to hear that, Seth. Basically the whole installation process changed between 1.1 and 1.5. And there have been a bunch of improvements since then; have you tried HEAD rather than 1.5b6?

Any more useful information in the crashlogs, or just that one error?

We see crashes like this from about 0.5 percent of our installed base with every update. We're using the top o' the trunk 1.5b6 sources. Sometimes the crashes are in NSNibLoading, other times in bindings, often just like the one described above. It seems that only a fraction of the application gets installed, and so it crashes in various places as missing things are needed. Our Sparkle feed is signed, and our app is code signed as well. No help from that.

It would be nice if Sparkle could checksum or verify the installed copy before relaunching to make sure it is complete.

I’m fairly sure this is from the Sparkle-needs-to-install-AFTER-host-quits bug.

Is there a fix coming for that?

Yes. Eventually. :)

Is there something I could try in the meantime, like adding an extra delay before relaunching?

I mean, a race condition is a race condition. Probably best not to try to duct tape over the whole.

You can take a look at the branch which includes this fix at http://github.com/uliwitness/Sparkle.

Unfortunately, it also includes a huge number of other changes I haven't had a chance to fully review, which is what's causing the delay.

I'm guessing these two files would contain the changes I want:

SUPlainInstaller.m
SUPlainInstallerInternals.m

That would be a good guess, but the update driver is changed as well to do different things on relaunch. As is the relaunch tool.

I feel like I'm operating on Spock's brain here... What do you think about just using Uli's branch instead? Has it been field tested? I've got to do something about all these update failures. The tech support load is ridiculous.

Yep. They're still coming in for me as well. I haven't looked at Uli's branch.

Uli's changes are in use in Elgato products, but they haven't been tested beyond those. If that's good enough for you, go for it.

I'm sorry you guys are getting so many problems from this. It seems to be an all-or-nothing thing: a few apps are hit really hard by this, while the others get nothing. I'm not really sure why.

Just another data point: since an app I work on added crash reporting, we're also getting sporadic reports from this. We're using a bastardised 1.5b6 + various bugfixes from trunk, but it doesn't sound like latest trunk would address this yet. Same crashes: image not found, after loading one of a few frameworks. (We do sign our updates, so it can't be that).

Looking forward to the Uli branch merge :)

I'm having this issue, too (running 1.5b6). Any news on the fix?

I think Sparkle is basically dead, though still on life support. How long has 1.5 been in beta? About 3 years? The Mac App Store is the way to go.

No news, sorry. I can't devote much time to Sparkle right now. Life support is about right.

Sorry to hear it...thanks for all your hard work on Sparkle! Us app store holdouts won't forget you :)

Sorry to dredge up the ancient past, but it looks like your branch is well ahead of Uli's (as mentioned in comment #22 as having a possible fix to this issue). Does anyone know if it is indeed fixed?