Debugger attachment woes

Question

Created Jan ’23

Replies 7

Boosts 0

Views 2.2k

Participants 2

Hello! I have a baffling situation happening on two different computers in which Xcode (14.2.0, on MacOS 12.6.1) is not being able to attach a debugger. This is happening for completely-fresh-from-scratch apps, both for MacOS and iOS apps. In both cases, the app eventually launches, but Xcode is not able to debug. Following the error message's suggestion, I looked in Console.app and as best as I can tell the proximate cause for the issue is task_for_pid failing; this message is preceded by a number of errors from com.apple.dt.instruments.dtarbiter:

Code validity check error: Error Domain=NSOSStatusErrorDomain Code=-67050 "(null)"

So my working hypothesis is that something is preventing the application from launching "normally" and so the debugger can't attach as it normally would.

Things I have tried:

Removing DerivedData, rebuilding
Making sure that "Developer Mode" is enabled (via DevToolsSecurity -enable)
Ensuring that the resulting binary has the com.apple.security.get-task-allow entitlement, and that "Code Signing Inject Base Entitlements" is set to "Yes"
Disabling Gatekeeper system-wide

I have also spent a while looking around with codesign and spctl. To my (admittedly non-expert) eye, codesign's output looks about right:

[~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] % codesign -d -vvv --entitlements :- Build/Products/Debug/ContentView.app/
Executable=/Users/bedricks/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj/Build/Products/Debug/ContentView.app/Contents/MacOS/ContentView
Identifier=org.bedrick.ContentView
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=1091 flags=0x10000(runtime) hashes=23+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=cf6f08586662c29420bf3ab7e673d0614b2c7717
CandidateCDHashFull sha256=cf6f08586662c29420bf3ab7e673d0614b2c771758ec9dce33fa7982fdab2267
Hash choices=sha256
CMSDigest=cf6f08586662c29420bf3ab7e673d0614b2c771758ec9dce33fa7982fdab2267
CMSDigestType=2CDHash=cf6f08586662c29420bf3ab7e673d0614b2c7717
Signature size=4785
Authority=Apple Development: Steven Bedrick (X8L6RQQBAR)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Jan 9, 2023 at 2:03:55 PM
Info.plist entries=19
TeamIdentifier=2E7A87Y536
Runtime Version=13.1.0
Sealed Resources version=2 rules=13 files=0
Internal requirements count=1 size=188
Warning: Specifying ':' in the path is deprecated and will not work in a future release
<?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.app-sandbox</key><true/><key>com.apple.security.files.user-selected.read-only</key><true/><key>com.apple.security.get-task-allow</key><true/></dict></plist>

If I ask codesign to --verify my .app bundle, this is what I get:

[~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] % codesign -vvvv -R="notarized" --check-notarization -vvvv Build/Products/Debug/ContentView.app/

Build/Products/Debug/ContentView.app/: valid on disk

Build/Products/Debug/ContentView.app/: satisfies its Designated Requirement

test-requirement: code failed to satisfy specified code requirement(s)

[~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] %

So something does appear to be "up" with the signature/notarization, but I am not sure how to get more information about what the issue might be (turning up the command's verbosity does not give more information). Now, turning to spctl:

[~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] % spctl -a -v --raw Build/Products/Debug/ContentView.app/
Build/Products/Debug/ContentView.app/: rejected
<?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
    <dict>
        <key>assessment:authority</key>
        <dict>
              <key>assessment:authority:flags</key>
              <integer>0</integer>
        </dict>
        <key>assessment:remote</key>
        <true/>
        <key>assessment:verdict</key>
        <false/>
     </dict>
</plist>

So Gatekeeper is clearly "unhappy" with this file; I had thought that apps launched via Xcode itself were supposed to bypass Gatekeeper, but maybe that's not true? And in any event, I am able to launch the resulting .app file from the Finder without any issues.

This is happening on two separate computers, so my next thought was that it might be some kind of issue with my Apple ID? But on a third computer my same Apple ID works just fine for signing and running apps for local development. As best as I can tell I've got them all configured the same way in terms of which certificate/team they are using, etc. though it is certainly possible that I messed that up somehow. They're all running the same version of Xcode and MacOS.

One (possibly relevant) difference is that the two non-working machines are managed by my work's IT department, and my user there is part of an ActiveDirectory profile of some kind. The working machine is my own personal laptop. All three machines have Gatekeeper enabled (I tried turning it off system-wide and it did not fix it), and on all three machines my user is part of the "admin" and "_developer" groups, at least according to the groups command. I don't know what-all sort of remote management / security software they may have installed, is it possible that something along those lines could globally prevent task_for_pid attachment?

Any thoughts, advice, debugging ideas, magical shell invocations, etc. would be most welcome. Thank you!

Boost

Answer 1

DTS Engineer OP

Apple

Jan ’23

So something does appear to be "up" with the signature/notarization

No, that’s not right. You’re asking codesign to do a notarisation check but the app isn’t notarised and so that part of it fails. Hence satisfies its Designated Requirement but failed to satisfy specified code requirement.

Your app is development signed (Apple Development: Steven Bedrick (X8L6RQQBAR)) and thus can’t possibly be notarised. However, it should run locally.

So Gatekeeper is clearly "unhappy" with this file

Right, because the app is development signed. Gatekeeper always rejects such things.

I had thought that apps launched via Xcode itself were supposed to bypass Gatekeeper, but maybe that's not true?

It’s not that Xcode bypasses Gatekeeper, but rather than Xcode doesn’t quarantine the app and Gatekeeper only kicks in if the code is quarantined [1].

One (possibly relevant) difference is that the two non-working machines are managed by my work's IT department

Are you sure they haven’t installed some sort of endpoint security software? That’s a common cause of weird problems like this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] That’s a simplification but it’s good enough for this discussion.

1

Answer 2

StevenBedrick OP

Jan ’23

Thank you so much for the quick reply - I clearly have a bit of confusion going on around in my mental model of how signing and notarization work, and will do some more reading. :-)

But more importantly, your question about endpoint security is spot-on - I don't know exactly what they are using, but I do know that it is some sort of endpoint security product. Do you happen to know any details about what sorts of things might be being configured or blocked via endpoint security that would be interfering with the debugger attachment, or tips about system/OS settings I might look for? If I know what to ask them to turn off or adjust, I have had good luck getting them to do so in the past.

-SB

0

Answer 3

StevenBedrick OP

Jan ’23

As an additional datapoint - I just looked via kextstat and don't see any third-party kexts loaded, so whatever I may be encountering at least looks like it's in user-space. It looks like we're running something called "Endpoint Protector" and then something called "ForeScout SecureConnector"; I do realize that digging into specific applications is well outside of what we can probably debug on this discussion board, but thought I'd mention them in case you'd encountered issues with those tools in the past. Thank you again for any tips or advice you might have!

0

Answer 4

StevenBedrick OP

Jan ’23

I just looked via and don't see any third-party kexts loaded, so whatever I may be encountering at least looks like it's in user-space.

🤦‍♂️ Upon further reading I have now learned that this appears to be the entire point of the modern ES sub-system; I have also found in the ES docs the events that, if they are being caught by whatever my computer is running, could be interfering with the debugger (e.g. es_event_trace and the es_event_get_task_* family of events, and maybe others).

So now I think I might be at the end of the line of what I can do in terms of this line of investigation (short of disabling ES), unless anybody knows of APIs or commands I can use to query for more information about what ES events are currently being monitored on my system, which seems like the sort of thing that is unlikely to be user-accessible...

0

Answer 5

DTS Engineer OP

Apple

Jan ’23

Accepted Answer

Do you happen to know any details about what sorts of things might be being configured or blocked … ?

No, sorry, I don’t have a lot of concrete experience with this stuff.

I think you should engage with your IS folks about this. Ask them whether it was their intention to block app development and, if not, work with them to confirm that it’s their ES setup that’s causing the problem. For example, you might:

Set up a fresh machine without their ES config.
Set up your app development environment and confirm that it works.
Then install their ES config.
Re-test your app development setup.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1

Answer 6

StevenBedrick OP

Jan ’23

I have an update! It does seem to have been an Endpoint Security issue. In my case, the FireEye ES tool (xagt) was causing the problem: I was able to get permission to temporarily remove it, and immediately the debugger started working flawlessly. So now I am working with our IT and security folks to figure out what specific bit of FireEye configuration we need to change, and how to do so. Thank you so much for your help, @eskimo!

0

Answer 7

StevenBedrick OP

Jan ’23

And a final update, in case anybody else comes along and finds this. FireEye/xagt apparently supports process exemption by process or path name, and this feature includes wildcard support. So our IT folks decided that the easiest fix was to tell xagt to allow/ignore anything running under /Applications/Xcode.app/* and that seems to have done the trick.

0