Crash during install/relaunch

[gregfu]

Sparkle version 1.5b6

The application is packaged using choctop into a dmg.
The application does install however during relaunch it crashes.

After the restart the application has a new version.

2009-03-06 19:16:35.354 NewApp[38846:7f0b] An uncaught exception was raised
2009-03-06 19:16:35.355 NewApp[38846:7f0b] launch path not accessible
2009-03-06 19:16:35.356 NewApp[38846:7f0b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'launch path not accessible'
2009-03-06 19:16:35.357 NewApp[38846:7f0b] Stack: (
    2516685067,
    2466119227,
    2516684523,
    2516684586,
    2436634314,
    2437122447,
    183735,
    176012,
    176252,
    2436515821,
    2436514708,
    2526916757,
    2526916434
)

[Session started at 2009-03-06 19:16:35 -0700.]
Loading program into debugger…
GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".warning: Unable to read symbols for "@loader_path/../Frameworks/Sparkle.framework/Versions/A/Sparkle" (file not found).
warning: Unable to read symbols from "Sparkle" (not yet mapped into memory).
Program loaded.
sharedlibrary apply-load-rules all
Attaching to program: `/Users/testUser/.Trash/NewApp (1.3).app 19-16-35-129.app/Contents/MacOS/NewApp', process 38846.
[Switching to process 38846 thread 0x7f0b]
[Switching to process 38846 thread 0x10b]
[Switching to process 38846 thread 0x10b]

[Andy Matuschak (andymatuschak)]

Sorry for the insanely long turnaround time.

Does this happen consistently, or is this an isolated incident? I thought we had checks for all this stuff... this must mean the app was present at the relaunch path and then it vanished.

[Nicholas Riley (njriley)]

I'm running into the same problem. But his only happens with the latest update of my application—it updates fine then Sparkle hangs forever on "installing update...".

(gdb) bt
#0 0x97c9d4e6 in objc_exception_throw ()
#1 0x99418138 in +[NSException raise:format:arguments:] ()
#2 0x994180aa in +[NSException raise:format:] ()
#3 0x98f618d1 in -[NSConcreteTask launchWithDictionary:] ()
#4 0x98f9fc5d in +[NSTask launchedTaskWithLaunchPath:arguments:] ()
#5 0x0005addf in -[SUUpdater installAndRestart:] ()

and I get the same output:

2010-03-27 21:40:08.487 Pester[62857:a0b] launch path not accessible

Any idea what's going on here?

[Andy Matuschak (andymatuschak)]

Nicholas, is this with Sparkle 1.5b6, or HEAD from Git?

[Nicholas Riley (njriley)]

This is with an older version of Sparkle—I'm not sure what version it is (is there a way to ask it?).

I tried putting a current Sparkle.framework into my older app that isn't updating, and it updated fine.

So I think there's something wrong with this update that is causing older versions of Sparkle to fail, but newer ones to work.

In summary:

Pester 1.1b7 - can update to 1.1b7 with older Sparkle
Pester 1.1b7 - CANNOT update to 1.1b8 with older Sparkle
Pester 1.1b7 - can update to 1.1b8 with newer Sparkle
Pester 1.1b8 - can update to 1.1b8 with newer Sparkle

Of course, the majority of my users are in situation #2. Can you think of some incompatibility I'm running into here?

[Nicholas Riley (njriley)]

If it'd help to see the exact scenario:

http://sabi.net/nriley/software/Pester-1.1b7.dmg
http://sabi.net/nriley/software/Pester-1.1b8.dmg
defaults write net.sabi.pester SUFeedURL http://sabi.net/nriley/software/Pester/updatez.xml #1.1b8
defaults write net.sabi.pester SUFeedURL http://sabi.net/nriley/software/Pester/updatex.xml #1.1b7

Thanks!

[Andy Matuschak (andymatuschak)]

Thanks very much for doing the legwork on this. At least it seems to be fixed now. A number of bugs related to updating via DMGs were fixed in the interim since 1.5b6, I'm afraid. I took a look at your appcast and archives, and they seem to work okay.

One idea: try distributing 1.1b8 via .zip?

[Nicholas Riley (njriley)]

Thanks, I tried a .zip but it broke the same way. I'm glad newer versions of Sparkle won't have the same problem.

Since it's actually updating fine, just not relaunching, I will just put a note in the release notes to tell people to quit and restart the app when it hangs.

[Geoff Barrall (geoffsignup)]

I'm having exactly the same issue (file is a zip in our case). Any further thoughts on resolution or workarounds would be very much appreciated as right now whenever one of our customers upgraded then they get a crash with the same exception.

Other than this I love Sparkle so thanks for creating such a great tool.

Please advise on any possible fix. Thanks!

[Andy Matuschak (andymatuschak)]

Geoff, are you using 1.5b6, or have you tried newer versions from Github?

[Mike Verandt (hagar06)]

Hi, I am experiencing exactly the same issue. I have tried both 1.5b6 and the newest version from Github.
Any help would be greatly appreciated as upgrading = crash at the moment!

Thanks in advance!

[I can provide the full stack trace if that helps]

Application Specific Information:
abort() called
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'launch path not accessible'
*** Call stack at first throw:
(
 0 CoreFoundation 0x00007fff823a7cc4 __exceptionPreprocess + 180
 1 libobjc.A.dylib 0x00007fff8395d0f3 objc_exception_throw + 45
 2 CoreFoundation 0x00007fff823a7ae7 +[NSException raise:format:arguments:] + 103
 3 CoreFoundation 0x00007fff823a7a74 +[NSException raise:format:] + 148
 4 Foundation 0x00007fff88907621 -[NSConcreteTask launchWithDictionary:] + 463
 5 Foundation 0x00007fff88910e13 +[NSTask launchedTaskWithLaunchPath:arguments:] + 215
 6 Sparkle 0x00000001000bebd8 load_dsa_key + 20655
 7 Sparkle 0x00000001000bcec9 load_dsa_key + 13216
 8 Sparkle 0x00000001000bcfab load_dsa_key + 13442
 9 Foundation 0x00007fff88884e8d __NSThread__main__ + 1429
 10 libSystem.B.dylib 0x00007fff84d05456 _pthread_start + 331
 11 libSystem.B.dylib 0x00007fff84d05309 thread_start + 13

[Andy Matuschak (andymatuschak)]

Wow. First reaction: how the heck does load_dsa_key make any sense in that backtrace? It just makes calls to the C libcrypto library and certainly doesn't use NSTask. So, maybe stack corruption.

If you can reproduce this, would you mind running it in the debugger (with a debug-symboled version of Sparkle) so that we can figure out what the heck is going on? In particular, it would be interesting to know what the launch path being passed to launchedTaskWithLaunchPath is.

[Mike Verandt (hagar06)]

I have no idea what is going on either. It's 100% reproducible so I will try running it with the debugger on! Could be a couple of days though.

[Manuel Massing (m-massing)]

Hmm,

I don't think load_dsa_key is not the culprit here, this is just an artifact of Sparkle
having been linked without debug symbols. At least I had a different backtrace when
looking into it. I don't have it at hand but I think the exception is thrown by the
process launcher when it attempts to execute "relaunch".

I am still unsure what caused the problem for me, but it is related to my packaging
done with cmake & BundleUtilites.
I solved the problems I had by copying the Sparkle.framework directory into my app bundle
instead of using cmake and BundleUtilites for the packaging.

So the problems are probably related to one of the following things done by BundleUtilites / cmake when creating
the distribution bundle:

1. Stripping the "relaunch" binary
2. Changing the library ID from @loader_path/../Frameworks/Sparkle.framework/Versions/A/Sparkle.framework
 to @executable_path/../Frameworks/Sparkle.framework/Versions/A/Sparkle.framework

(Probably the first - it might be related to the fact that I built it against the 10.5 SDK. I've had the experience
that stripping such a binary can lead to unresolved symbols)

[Manuel Massing (m-massing)]

Addendum: for me, the problem had the same backtrace as the one from Nicholas Riley (as posted above).