Repository navigation
Fix gitx CLI crash when GitX is not running (Sparkle Updater.app steals the bundle identifier) - #560
Merged
Conversation
Passing PRODUCT_BUNDLE_IDENTIFIER=net.phere.GitX on the xcodebuild
command line overrides the setting for every target in the workspace,
including Sparkle's Updater.app built from the submodule. Since the
Sparkle 2.9.3 bump, Updater.app's Info.plist takes its identifier from
that build setting, so released bundles contain two bundles claiming
net.phere.GitX: the app itself and
GitX.app/Contents/Frameworks/Sparkle.framework/Versions/B/Updater.app.
When the gitx CLI then asks Scripting Bridge for net.phere.GitX while
the app is not running, LaunchServices can resolve to the Updater.app,
which has no scripting definition, and the CLI crashes:
warning: failed to get scripting definition from
.../Sparkle.framework/Versions/B/Updater.app; it may not be scriptable.
*** Terminating app due to uncaught exception 'NSInvalidArgumentException',
reason: '-[SBApplication open:withOptions:]: unrecognized selector ...'
The override is redundant anyway: every target already sets its own
PRODUCT_BUNDLE_IDENTIFIER in project.pbxproj (net.phere.GitX for the
app, net.phere.gitx-cli for the CLI).
The CLI ships inside the app bundle at GitX.app/Contents/Resources/gitx, so derive the app's URL from the tool's own (symlink-resolved) path and target it with -[SBApplication applicationWithURL:]. Resolving by bundle identifier is fragile: if any other bundle on disk claims net.phere.GitX (as Sparkle's embedded Updater.app did in releases built with a global PRODUCT_BUNDLE_IDENTIFIER override), LaunchServices can return a bundle without our scripting definition and every scripting call crashes with '-[SBApplication open:withOptions:]: unrecognized selector'. The bundle-identifier lookup is kept as a fallback for running the tool outside an app bundle (e.g. straight from the build directory). This makes the CLI immune to broken bundles already installed by existing releases, complementing the workflow fix in the previous commit.
Contributor
|
Sorry, I've to revert this. The merge to master shows me this: Next time, I've to make same PR on upstream, to see if it's working |
Contributor
|
Ahh, it's a general issue. Sorry for the noise |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symptom
Since recent releases, running
gitxfrom the command line crashes whenever GitX.app is not already running:Launching the app first and re-running
gitxworks, which is the tell-tale for the root cause below.Root cause
The archive step in
BuildPR.ymlpassesPRODUCT_BUNDLE_IDENTIFIER=net.phere.GitXon thexcodebuildcommand line (added in da70aa5). A command-line build setting overrides every target in the workspace, including Sparkle'sUpdater.appbuilt from the submodule. Since the Sparkle 2.9.3 bump (#556 / 68f8324), Updater.app's Info.plist takes its identifier from$(PRODUCT_BUNDLE_IDENTIFIER), so shipped bundles contain two bundles claimingnet.phere.GitX:/Applications/GitX.app(the real app), and/Applications/GitX.app/Contents/Frameworks/Sparkle.framework/Versions/B/Updater.appThe CLI resolves the app with
[SBApplication applicationWithBundleIdentifier:@"net.phere.GitX"]. When the app is not running, LaunchServices resolves that identifier ambiguously and can return the Updater.app — which has no scripting definition (hence the warning), so the Scripting Bridge proxy only knows the standard suite andopen:withOptions:throwsunrecognized selector. When the app is already running, SBApplication binds to the running process and everything works.Fix (two commits)
PRODUCT_BUNDLE_IDENTIFIERinproject.pbxproj(net.phere.GitXfor the app,net.phere.gitx-clifor the CLI). A comment in the workflow explains why it must not come back.gitxships atGitX.app/Contents/Resources/gitx, derive the app URL from the tool's own symlink-resolved path and useapplicationWithURL:(falling back to the bundle-identifier lookup when running outside a bundle, e.g. from the build directory). This also makes new CLIs immune to the broken bundles installed by existing releases, which will remain on users' disks until they update.Verified locally: with the identifier override,
Updater.app/Contents/Info.plistin the shipped 1.5-HEAD app containsnet.phere.GitX(upstream Sparkle usesorg.sparkle-project.Sparkle.Updater), and the crash reproduces 100% from a cold start.