Debugging fails with "Error 1" if hardened runtime is enabled

Hi,


I'm unable to debug my mac application under XCode when Hardened Runtime is enabled. I'm getting 'Message from debugger: Error 1'.


lldb -p <pid> gives the same error:

error: attach failed: Error 1


Disabling hardened runtime solves the problem, but I'm wondering if there's a way to debug with the hardened runtime enabled, and why I'm getting such a cryptic error message.


Using XCode 10.2.1 on macOS 10.14.5.

Replies

I encountered this error too running XCode 10.2.1 on macOS 10.14.5.


In my case, this didn't have to do with Hardened Runtime, but rather my "Debug Process As" setting.


I had to edit my scheme settings, and instead of debugging the process as me, I had to debug process as root. Not sure why this works, but hope it's helpful.


This problem is most likely related to entitlements. In general, the hardened runtime prevents the debugger from attaching to your process. When you do a Product > Run, Xcode adds an entitlement to your app (

com.apple.security.get-task-allow
) that allows the debugger to attach. In other situations — for example, when you do a Product > Archive — that’s not the case.

IMPORTANT This entitlement isn’t added to your

.entitlements
file, but directly to the app. Use this command to see it:
$ codesign -d --entitlements :- /path/to/your.app

It sounds like Xcode isn’t adding this entitlement for you. One possibility is that you’ve disabled the Code Signing Inject Base Entitlements (

CODE_SIGN_INJECT_BASE_ENTITLEMENTS
) build setting.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I saw this problem too, with a simple command-line C++ tool. My project(s) have "Automatically manage signing" checked, and I verified

CODE_SIGN_INJECT_BASE_ENTITLEMENTS
was Yes for Debug and Release. I'm on Xcode 10.3, Mac OS 10.14.6.


Debugging the tool worked fine on the machine where I created the project (same Xcode/OSX versions), but checking the project out of git on a different machine, this problem occurred - I hit run but it never hits the entry point of main and the same error is reported (but oddly it hides the console & you have to open it to see it). Like the poster above, running as root works around the issue, but for many reasons I do not want to do that.


Messing with my signing certificate ended up fixing the problem. In Keychain access I noticed my Mac OS Developer certificate was in System Roots but not in login. I dragged it into login. Then in the Xcode project Info settings (showing signing setup), there was an error message saying I needed to remove the current signing certificate in order to pick up the correct one. I clicked okay and the warning went away. Now, for some reason, there are two different copies of my Mac Developer signing certificate in keychain - same ID#, one dated a month ago, another dated today.


The good news is, it seems to be fixed, though there seems to be something a little off with the "Automatically manage signing" setting and keychain's management of certificates - either that or I did something wrong while setting it up (with a different project).

I was able to work around this by setting the "Code Signing Identity" to "Sign to Run Localy" and also changing "Enable Hardend Runtime" to "No". Both of these settings are in the build settings of the target under signing.

It's still not working for me. I guessed it had something to do with my manual signing settings. But now I've switch to automatic signing and it still doesn't work.


My settings:


CODE_SIGN_STYLE = Automatic
CODE_SIGN_INJECT_BASE_ENTITLEMENTS = YES

From the build log:


CodeSign /Users/joostn/Library/Developer/Xcode/DerivedData/MyProduct-fvgvvkwupoapzkazuzzceweakusy/Build/Products/Release/MyProduct.app (in target 'MyProduct' from project 'MyProduct')
    cd /Volumes/devel/wxwprojects_MyProduct12/MyProduct/Project/XCode
    export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
  
Signing Identity:     "-"


    /usr/bin/codesign --force --sign - -o runtime --entitlements /Users/joostn/Library/Developer/Xcode/DerivedData/MyProduct-fvgvvkwupoapzkazuzzceweakusy/Build/Intermediates.noindex/MyProduct.build/Release/MyProduct.build/MyProduct.app.xcent /Users/joostn/Library/Developer/Xcode/DerivedData/MyProduct-fvgvvkwupoapzkazuzzceweakusy/Build/Products/Release/MyProduct.app

/Users/joostn/Library/Developer/Xcode/DerivedData/MyProduct-fvgvvkwupoapzkazuzzceweakusy/Build/Products/Release/MyProduct.app: replacing existing signature


The .xcent file appears to contain no entitlements:

cat /Users/joostn/Library/Developer/Xcode/DerivedData/MyProduct-fvgvvkwupoapzkazuzzceweakusy/Build/Intermediates.noindex/MyProduct.build/Release/MyProduct.build/MyProduct.app.xcent

And indeed codesign -d --entitlements reports that my app has no entitlements.


Any ideas?

The .xcent file appears to contain no entitlements:


cat /Users/joostn/Library/Developer/Xcode/DerivedData/MyProduct-fvgvvkwupoapzkazuzzceweakusy/Build/Intermediates.noindex/MyProduct.build/Release/MyProduct.build/MyProduct.app.xcent

<?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/>

</plist>

Any ideas?

I recommend that you create a new test project and try things there. If that works, you know that Xcode is behaving itself in general, and that the problem you’re seeing is tied to your main project. At that point you can start comparing your main project to your test project to see what’s different.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi Guys,


I have a similar problem except I am trying to debug a plug-in (developed as a bundle) that is loaded by another application (which I do not develop). I have everything set up as I have for years but after upgrading to XCode 11 from XCode 9, I cannot get the main application to launch for debugging. When I Launch the application manually (which loads my bundle) and I try to attach to the application process from XCode, the same error occurs. The details I get are


Could not attach to pid : “2121”

Domain: IDEDebugSessionErrorDomain

Code: 3

Failure Reason: Error 1

--

Error 1

Domain: IDEDebugSessionErrorDomain

Code: 3

--


Any help would be much appreciated.


Mike

I cannot get the main application to launch for debugging.

Let’s try a basic test:

  1. Run the host app from the Finder.

  2. In Xcode, create a new test project from the macOS > Bundle template.

  3. Choose Debug > Attach to Process > HostAppName.

Does it attach?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi Quinn,


I have a similar situation to the previous poster. I have to debug VST3 and AU plugins I develop in multiple hosts from various companies. Whether launching the hosts from the debugger or attaching to their processes after they are running I get the "Error 1". I'm running Mac OS 10.15.2.


Is there a way to restore the debugging behavior I'm used to from previous OS versions system-wide for development? If not, do you have any other suggestions?


thanks and best,

*****

Madrona Labs

My general advice here is that you work with the host developers to get a version of their app that’s appropriate for plug-in development.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Convincing all of the host developers to deploy special debugging builds on a regular basis can only be described as a long-term project. I'll mention it when I get a chance.


Meanwhile, I found that disabling System Integrity Protection, as described at the following link, lets me get my work done. https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/ConfiguringSystemIntegrityProtection/ConfiguringSystemIntegrityProtection.html

It's now February 2020 and I can confirm this issue is still present with the Xcode 11.4 beta. The "new" build system produces this issue; the "legacy" build system works perfectly.


I filed a Radar about this 11 months ago and have now opened a DTS incident to try to get SOMEONE at Apple to look into the problem before they deprecate and remove the legacy build system.

This is the first time that anyone has mentioned a difference between the new and legacy build systems on this thread. Clearly I’m missing some context here.

I filed a Radar about this 11 months ago

What was the bug number?

[I] have now opened a DTS incident

And that incident number? [If you don’t feel like sharing that publicly, please email me at the address in my signature. Make sure to reference this thread because I get a lot of email (-: ]

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Just to close the loop on this one, I had cause to dig into this issue in depth recently. After much spelunking, I determined that the Deployment Postprocessing (

DEPLOYMENT_POSTPROCESSING
) build setting was triggering this problem. With Deployment Postprocessing set, the resulting app was missing the
com.apple.security.get-task-allow
entitlement. With it clear, the app gets that entitlement just like it does with the legacy build system.

It’s not at all clear why this is happening, but it certainly seems like a bug to me (especially as it only affects the new build system). We’re tracking this as FB7590182 (r. 59620184).

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"