Xcode build issues with MacOS Monterey

[Johste]

Hi,

Issues started appearing when we upgraded the build agent to MacOS Monterey.
References to similar issues found on the web seem related to older versions of golang.
Known workarounds don’t seem applicable.
Anything we can do to avoid the issue?

Reproduced in Xcode 12.4 and Xcode 13.
Identical CI setup builds fine in Catalina and Big Sur.
We’re using Unity 2019.4.23f1

/bin/sh -c /Users/agent007/Library/Developer/Xcode/DerivedData/Unity-iPhone-brjkcdstlthovoajtjgnpunvevqi/Build/Intermediates.noindex/ArchiveIntermediates/Unity-iPhone/IntermediateBuildFilesPath/Unity-iPhone.build/Release-iphoneos/UnityFramework.build/Script-F5B74F07A4691D1F0D47112F.sh
fatal error: runtime: bsdthread_register error

runtime stack:
runtime.throw(0x1622388, 0x21)
    /usr/local/go/src/runtime/panic.go:605 +0x95 fp=0x7ff7bfef39b0 sp=0x7ff7bfef3990 pc=0x1029c75
runtime.goenvs()
    /usr/local/go/src/runtime/os_darwin.go:108 +0x83 fp=0x7ff7bfef39e0 sp=0x7ff7bfef39b0 pc=0x1027513
runtime.schedinit()
    /usr/local/go/src/runtime/proc.go:492 +0xa1 fp=0x7ff7bfef3a20 sp=0x7ff7bfef39e0 pc=0x102c651
runtime.rt0_go(0x7ff7bfef3a50, 0x3, 0x7ff7bfef3a50, 0x1000000, 0x3, 0x7ff7bfef4d90, 0x7ff7bfef4e06, 0x7ff7bfef4e12, 0x0, 0x7ff7bfef4eef, ...)
    /usr/local/go/src/runtime/asm_amd64.s:175 +0x1eb fp=0x7ff7bfef3a28 sp=0x7ff7bfef3a20 pc=0x10540fb
Command PhaseScriptExecution failed with a nonzero exit code

[jerome-lacoste]

My understanding is that this is an old issue triggered from Go on Mac and it can be avoided if the programs (in this case usymtool) are built by changing the way libraries are linked into the final binary (e.g. with)

export DYLD_LIBRARY_PATH=
go build -ldflags -linkmode=external ....

and maybe by using go >= 1.11.

https://github.com/golang/go/issues/8801#issuecomment-66460009
https://groups.google.com/g/golang-nuts/c/HtcZc3wO-rw

Go 1.11 Release Notes - The Go Programming Language

Anyone from Unity can comment on this? Maybe ** @UnityLouisaRogers ?**

[Johste]

Updating Unity to 2019.4.31f1 seem to have resolved this issue.

[fechy]

@Johste

Updating Unity to 2019.4.31f1 seem to have resolved this issue.

Unfortunately, this does not work. Still getting the same issue

[dmitry_vasiliev]

Here are what can be done:

1. Remove Unity Process symbols or Process symbols step from Build Phases in both Unity-iPhone and UnityFramework targets.

   

2. Or you can empty this script:
   /Applications/Unity/Hub/Editor/[UnityVersion]/PlaybackEngines/iOSSupport/Trampoline/process_symbols.sh. Remove everything except #!/bin/sh.

BE AWARE: Crash stack traces in Unity Dashboard will become unreadable.

[programacion-6]

@dmitry_vasiliev Great !! That solution works.

But it’s strange. That problem only occurs when building from BatchMode. When building directly from the Unity Editor we don’t have the problem.

At first we wondered if It was related to our CI instance not having enough permissions but after some research is clearly not.

It is possible we might avoid the error by changing our build options on code? Or it’s an inevitable bug from iOS batchmode build?

Here our command for building to iOS:

public static void BuildiOS()
{


    BuildPlayerOptions buildPlayerOptions = new BuildPlayerOptions();

    buildPlayerOptions.locationPathName = "Users/MyUser/.jenkins/Builds/" + newBuildName;
    buildPlayerOptions.target = BuildTarget.iOS;

    List<string> listScenes = new List<string>();
    foreach (var s in EditorBuildSettings.scenes)
    {
        if (s.enabled)
            listScenes.Add(s.path);
    }

    buildPlayerOptions.scenes = listScenes.ToArray();
    buildPlayerOptions.options = BuildOptions.None;

    BuildPipeline.BuildPlayer(buildPlayerOptions);


}

[dmitry_vasiliev]

@programacion-6
Found the difference between batchmode and without batchmode. It seems that in batchmode Unity sets this environment argument SYNCHRONOUS_SYMBOL_PROCESSING to TRUE (don’t know why). And it is used by the script below to upload debug symbols.
Adding SYNCHRONOUS_SYMBOL_PROCESSING=FALSE to the xcodebuild command will fix the build.
Example:
/usr/bin/xcodebuild -scheme Unity-iPhone -workspace [workspace] -configuration Release clean archive -archivePath [archivePath] DEVELOPMENT_TEAM=[teamID] -allowProvisioningUpdates SYNCHRONOUS_SYMBOL_PROCESSING=FALSE

The script which uploads debug symbols:

#!/bin/sh

# process_symbols
#
# Copyright (c) 2015 Unity Technologies. All rights reserved.

if [ "${SYNCHRONOUS_SYMBOL_PROCESSING}" = "TRUE" ]; then
"$PROJECT_DIR/usymtool" -symbolPath "$DWARF_DSYM_FOLDER_PATH/$DWARF_DSYM_FILE_NAME"
else
nohup "$PROJECT_DIR/usymtool" -symbolPath "$DWARF_DSYM_FOLDER_PATH/$DWARF_DSYM_FILE_NAME" > /dev/null 2>&1 &
disown
fi

UPD: Ok, it looks like without SYNCHRONOUS_SYMBOL_PROCESSING you won’t see a log in console and terminating xcodebuild won’t stop DSYM uploading if its already ongoing. When building directly from the Unity Editor the script still fails, but doesn’t affect the main process, which is xcodebuild.

[an_easytarget]

We were able to do something like this to get the local builds working for dev purposes.

proj.SetBuildProperty(targetGuid, "USYM_UPLOAD_AUTH_TOKEN", "NONE");
proj.SetBuildProperty(targetGuid, "SYNCHRONOUS_SYMBOL_PROCESSING", "False");

[PostProcessBuildAttribute(1)]
public static void OnPostprocessBuild(BuildTarget target, string pathToBuiltProject) {
        if (target == BuildTarget.iOS)
        {
            string projPath = PBXProject.GetPBXProjectPath(buildPath);
            PBXProject proj = new PBXProject();
            proj.ReadFromFile(projPath);

            if (proj != null)
            {
                string targetGuid = proj.TargetGuidByName(PBXProject.GetUnityTargetName());
                proj.SetBuildProperty(targetGuid, "USYM_UPLOAD_AUTH_TOKEN", "NONE");
                proj.SetBuildProperty(targetGuid, "SYNCHRONOUS_SYMBOL_PROCESSING", "False");
                proj.WriteToFile(projPath);
            }
        }
}

Unity - Scripting API: PostProcessBuildAttribute

[Benjamin-Gooding]

For those who stumble upon this post. I reached out to our Cloud Diagnostics team and this issue is related to how Monterey interacts with applications built using older version of Go. This is a known issue when a tool written with GoLang was built using a version of Go older than 1.11. The Cloud Diagnostics tool was built using GoLang and older versions of Unity are impacted by this bug.

The Cloud Diagnostics team released a fix for this and versions of Unity including, or newer than the following should not result in a BSD Thread Error when running on Monterey: 2019.4.25f1, 2020.3.5f1, 2021.2.0a1, and any version of 2022.

[tchapman_lumineye]

@Benjamin-Gooding

For those who stumble upon this post. I reached out to our Cloud Diagnostics team and this issue is related to how Monterey interacts with applications built using older version of Go. This is a known issue when a tool written with GoLang was built using a version of Go older than 1.11. The Cloud Diagnostics tool was built using GoLang and older versions of Unity are impacted by this bug.

The Cloud Diagnostics team released a fix for this and versions of Unity including, or newer than the following should not result in a BSD Thread Error when running on Monterey: 2019.4.25f1, 2020.3.5f1, 2021.2.0a1, and any version of 2022.

Thanks for noting this here. It might also be worth mentioning that our iOS Cloud Builds started intermittently failing about 2 weeks ago (August 5th 2022) due to this error with no relevant code changes and they were using 2020.3.4. We upgraded those builds to latest 2020.3 (2020.3.37f1 at time of this writing) and it doesn’t seem to have resolved the issue. As you can see below, the failures are pretty sporadic and started with #189. #199 and #196 were started at the same time with different versions and were still inconsistent. For context, the only different between Nightly and Prod currently is the icon. Other than that they’re identical builds. Any suggestions?

[JackmanGomel]

@Benjamin-Gooding

For those who stumble upon this post. I reached out to our Cloud Diagnostics team and this issue is related to how Monterey interacts with applications built using older version of Go. This is a known issue when a tool written with GoLang was built using a version of Go older than 1.11. The Cloud Diagnostics tool was built using GoLang and older versions of Unity are impacted by this bug.

The Cloud Diagnostics team released a fix for this and versions of Unity including, or newer than the following should not result in a BSD Thread Error when running on Monterey: 2019.4.25f1, 2020.3.5f1, 2021.2.0a1, and any version of 2022.

Hello. I use 2022.2.2f1 but I get the error