I have a swift 5.4 package manager project with an executable target I want to profile in Instruments.
I Cmd+I to profile which launches instruments. I pick allocations.
then push the record button.
im asked to authorise and doesn’t matter whether I use fingerprint or password I always get the error:
(before run started) Failed to gain authorization
any ideas?
instruments 12.5 xcode 11.5 swift 5.4 2020 M1 MBP 13”
Hi there!
This is most likely due to your application not being signed with a debugging entitlement.
If you run: codesign -dvvv --entitlements=- <path-to-app> — do you see get-task-allow entitlement listed in there?
If not — there are a few things you should check for:
— Are you signing your Release scheme build with a developer certificate?
— Make sure you're not overriding CODE_SIGN_INJECT_BASE_ENTITLEMENTS build setting, it should be set to YES by default.
Please let us know what's the outcome and we'll continue our investigation based on the codesign output.
Kacper
Hi Kacper, thanks for reply.
So running the above:
% codesign -dvvv --entitlements=- .build/arm64-apple-macosx/release/perftool
Executable=/Users/adrianm/Projects/soapybasic/SoapyBasicLib/.build/arm64-apple-macosx/release/perftool
Identifier=perftool
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=6561 flags=0x20002(adhoc,linker-signed) hashes=202+0 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=dd4650a99e52e98e224350b0150293e990b96418
CandidateCDHashFull sha256=dd4650a99e52e98e224350b0150293e990b9641817aa23d58dad7899a62adc33
Hash choices=sha256
CMSDigest=dd4650a99e52e98e224350b0150293e990b9641817aa23d58dad7899a62adc33
CMSDigestType=2
CDHash=dd4650a99e52e98e224350b0150293e990b96418
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none
I tested this on a simple Swift Xcode project and I get the entitlements in the plist and can Instrument the app. But that's an app, not a package managed by Swift Package Manager.
Perhaps that is the key difference. Need to figure out how to sign a Swift Package?
If I create a simple Xcode application (eg a SwiftUI app) and then import my Swift package as a dependency, then the resulting application can be profiled.
I noticed that none of the features in Xcode for doing build settings are available in pure Swift Packages, so perhaps that is why.
Hi there!
This is most likely due to your application not being signed with a debugging entitlement.
If you run: codesign -dvvv --entitlements=- <path-to-app> — do you see get-task-allow entitlement listed in there?
If not — there are a few things you should check for:
— Are you signing your Release scheme build with a developer certificate?
— Make sure you're not overriding CODE_SIGN_INJECT_BASE_ENTITLEMENTS build setting, it should be set to YES by default.
Please let us know what's the outcome and we'll continue our investigation based on the codesign output.
Kacper
Hi Kacper, thanks for reply.
So running the above:
% codesign -dvvv --entitlements=- .build/arm64-apple-macosx/release/perftool
Executable=/Users/adrianm/Projects/soapybasic/SoapyBasicLib/.build/arm64-apple-macosx/release/perftool
Identifier=perftool
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=6561 flags=0x20002(adhoc,linker-signed) hashes=202+0 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=dd4650a99e52e98e224350b0150293e990b96418
CandidateCDHashFull sha256=dd4650a99e52e98e224350b0150293e990b9641817aa23d58dad7899a62adc33
Hash choices=sha256
CMSDigest=dd4650a99e52e98e224350b0150293e990b9641817aa23d58dad7899a62adc33
CMSDigestType=2
CDHash=dd4650a99e52e98e224350b0150293e990b96418
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none
I tested this on a simple Swift Xcode project and I get the entitlements in the plist and can Instrument the app. But that's an app, not a package managed by Swift Package Manager.
Perhaps that is the key difference. Need to figure out how to sign a Swift Package?
If I create a simple Xcode application (eg a SwiftUI app) and then import my Swift package as a dependency, then the resulting application can be profiled.
I noticed that none of the features in Xcode for doing build settings are available in pure Swift Packages, so perhaps that is why.
I suspect the answer here is that Instruments can't attach to unsigned code and executable targets build by the Swift Package Manager tooling doesn't sign code.
This makes sense because it's meant to be open source and cross platform, yet code signing is a Apple thing.
As a workaround, I created a simple Command Line Tool Xcode project and added my Swift Package as a dependency, with the tool's main.swift just calling into the package. Xcode will happily code sign everything and Instruments runs just fine.
I suppose an open/related question is: can Instruments/macOS be persuaded to instrument unsigned code?
I get the same error using the Xojo IDE (url not permitted). The debugged app has an ad-hoc code certificate. Shouldn't this be enough for Instruments?
macOS 11.2 and Instruments 12.5.
Problem solved: was missing the correct entitlement.
I'm also encountering this error while trying to profile an executable compiled with Rust (Xcode isn't involved). I know that's not a super-common workflow, but Instruments has been very helpful for profiling Rust code in the past. I have yet to find a workaround.
Hi kettlecorn. Have you found a solution?
Workaround:
Create a file called debug.plist. Put the following text in the new file:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.security.get-task-allow</key><true/></dict></plist>
Then, sign your app (or re-sign it) with the following shell (Terminal.app) command:
$ codesign -s - -v -f --entitlements /path/to/debug.plist /path/to/your/executable
-
—
adrianm
-
—
tdegeus
Add a CommentNote I get the same if I try to profile any arbitrary running process.
I'm getting the same error for a C++ code that I compile with the system's clang. If instruments cannot profile code that I compile myself on my system it becomes entirely useless. In this case I really should not have to worry about code signing as is suggested below.