A number of customers reported an issue with Xcode 7.3 where the xcodebuild command would fail without any error message and would return the exit code 65 to the console:
It is currently not clear what exactly is causing the issue, and we are investigating the problem, trying out possible solutions and testing them with a set of sample projects.
We appreciate your patience while we work on the issue. We will continue to update this thread with any advances in the investigation.
Hello. what is the status of this issue? We are getting hit by it hard recently. An example of failed builds sequence, eventually fixed by stubborn Rebuilding: https://circleci.com/gh/kitt-browser/kitt/466
timed out in 467, success in 468
Thank you
Please contact support about this and we’ll credit you for minutes used on these exit 65 failures. We’re still investigating the cause of these flakey failures, but we don’t want you paying extra for them.
I understand this must be terribly frustrating. We have people spending time trying to diagnose this (and have been looking at this for awhile unfortunately). It appears that Error Code 65 is a more generic error code which makes this diagnosis harder as it likely pertains to several possibly unrelated topics.
In our research, we’ve found that it appears to hit many OS X platforms (including complements and competitors). Because it’s increasingly common, we have tried to diagnose if hosting has a common cause. It appears to have started happening more since the last version of XCode as well. We feel a similar frustration ourselves as we continue to try and solve this.
My team recently shipped a change such that
you won’t be charged for the minutes spent where a build fails due to Error Code 65
We will auto-retry that build for you up to 3x (as we’ve seen repeatedly this bug can be intermittent).
It doesn’t solve the issue (I wish we could do that as easily!) but I hope it shows a sign of respect for your situation. Thanks for being CircleCI customers.
Is there a way to determine how many minutes were credited back due to Error Code 65? I burned through a ton of builds trying to diagnose and fix this issue over the last month.
One thing I have learned that might shed some light, my issues seem related to the tee command that Fastlane scan emits as part of the build step.
Fastlane scan emits this:
set -o pipefail && env NSUnbufferedIO=YES xcodebuild -workspace ./the_workspace.xcworkspace -scheme 'the_scheme' -configuration 'Test' -destination 'platform=iOS Simulator,OS=9.3,name=iPhone 5s' -enableCodeCoverage YES build test | tee '/Users/distiller/Library/Logs/scan/App-log.log' | xcpretty
If I execute this command directly as part of my circle.yml file it will still fail as described in this thread but both Fastlane and this command run fine on my team’s local machines.
Dropping the tee command allows it to succeed reliably on Circle.
Here is the command I’m currently using in my circle.yml file:
Is there any followup for this issue? I’m continuing to get seemingly random build/test failures with error code 65 and it’s very frustrating to have to keep rebuilding until it works.
Nothing definite yet but our mobile team has isolated some really promising root causes and we’re testing possible solutions with 1-2 alpha customers now. As soon as we have it solved, we will update.
EDIT Jan 16 2017: We no longer recommend using UUIDs to start simulators. The OS X image has been updated to resolve the underlying issue, and using UUIDs is no longer necessary. Please check out this post for examples of how to choose the simulators by name.
Hey everyone,
this issue is for most people very likely caused by a timeout because the iOS simulator not starting fast enough.
A workaround that has been tested by us is starting the GUI simulator first with:
distiller-build-8:~ distiller$ xcrun instruments -w ‘A70FE3C7-756F-44BF-BE46-68663FAE2EE3’
2016-07-28 15:34:43.398 instruments[3140:14974] [MT] DVTSDK: Skipped SDK /Applications/Xcode-7.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.1.sdk; its version (7.1) is below required minimum (9.3) for the iphonesimulator platform.
2016-07-28 15:34:43.399 instruments[3140:14974] [MT] DVTSDK: Skipped SDK /Applications/Xcode-7.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator8.4.sdk; its version (8.4) is below required minimum (9.3) for the iphonesimulator platform.
2016-07-28 15:34:43.399 instruments[3140:14974] [MT] DVTSDK: Skipped SDK /Applications/Xcode-7.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.0.sdk; its version (9.0) is below required minimum (9.3) for the iphonesimulator platform.
2016-07-28 15:34:43.400 instruments[3140:14974] [MT] DVTSDK: Skipped SDK /Applications/Xcode-7.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.1.sdk; its version (9.1) is below required minimum (9.3) for the iphonesimulator platform.
2016-07-28 15:34:43.400 instruments[3140:14974] [MT] DVTSDK: Skipped SDK /Applications/Xcode-7.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk; its version (9.2) is below required minimum (9.3) for the iphonesimulator platform.
Waiting for device to boot…
Instruments Usage Error: No template (-t) specified
instruments, version 7.3 (60134)
this is indeed an issue with the a template, but simply because we don’t specify one to make it launch quicker. You don’t want to profile your application in any way, you’re simply using xcrun instruments because Instruments is able to launch the GUI iOS simulator reliably (which xcrun simctl isn’t). The Instruments command itself fails, but it launches the iOS simulator anyways. Please add || true at the very end of your command to suppress a non-0 exit code.
this might happen. I’ve seen this before, you might be a special case and this fix wont do the job on your project. I’d love to take a look. Please contact our Support and reference this text, so that I can find your ticket.
The xcrun instruments trick seems mostly to work for us, with occasional failures that are fixed by retrying. Quite frustrating that there doesn’t seem to be a reliable solution.
EDIT: It looks like the inconsistency may have just been from invoking xcrun instruments with the wrong simulator UUID; builds have been fine since I fixed that.