runtime: stalls under Rosetta2 with MacOS 14.5

[flostadler]

Go version

go version go1.22.4 darwin/arm64

Output of go env in your module/workspace:

n/a

What did you do?

I have a go amd64 binary that is running fine with Rosetta2 in MacOS 14.4 and earlier. After upgrading to MacOS 14.5 it stalls.

As a workaround, running the binary with GODEBUG=asyncpreemptoff=1 works.

The binary is https://github.com/pulumi/pulumi-aws with version v6.42.0+.

I wasn't able to create a minimal example that triggers this, but to reproduce it you can do the following (you need an AWS account but nothing gets created):

• install pulumi: brew install pulumi
• create project: mkdir rosetta-stall-repro && cd rosetta-stall-repro && pulumi new aws-typescript
• select the affected version (this in turn downloads the go binary): yarn upgrade @pulumi/[email protected]
• run the arm64 binary (works): pulumi preview
• download the amd64 binary:
  • pushd ~/.pulumi/plugins/resource-aws-v6.42.0
  • wget https://github.com/pulumi/pulumi-aws/releases/download/v6.42.0/pulumi-resource-aws-v6.42.0-darwin-amd64.tar.gz
  • tar -xvzf pulumi-resource-aws-v6.42.0-darwin-amd64.tar.gz
  • popd
• run the amd64 binary (stalls): pulumi preview

What did you see happen?

Getting the following error before the runtime stalls:

assertion failed [arm_interval().contains(address)]: code fragment does not contain the given arm address
(CodeFragmentMetadata.cpp:48 instruction_extents_for_arm_address)

CodeFragmentMetadata.cpp seems to be part of Rosetta2:

strings /Library/Apple/usr/libexec/oah/runtime | grep CodeFragmentMetadata.cpp
CodeFragmentMetadata.cpp

What did you expect to see?

The runtime shouldn't stall and execute normally.

[gabyhelp]

Related Issues and Documentation

• runtime: stalls under Rosetta 2 #42700 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

Why are you using an amd64 binary when an arm64 one is available?

[cherrymui]

Thanks for reporting. This looks like a bug in Rosetta2. The assertion failure is Rosetta 2's internal failure.

Do you have a simpler reproducer, without an AWS account? Does this reproduce consistently, or just fail occasionally? With more information we can report to Apple and have them reproduce. Thanks.

[mknyszek]

In triage @cherrymui mentioned that she tried to reproduce on the latest macOS at the time (14.5 and 15.0 beta) and was unable to (at least with all.bash).

[flostadler]

@cherrymui @mknyszek I know this is a very convoluted repro, but we sadly don't have a simpler one :/ It is failing constantly for us. Let me know if I can help you repro in any way!

[cherrymui]

If you could make it self-contained, without an AWS account, it would be helpful. Even if it is just a binary, we can point the binary and let Apple know that, run that binary in Rosetta 2 and it fails. Thanks.

[nina-nee]

There is a relatively simple way to replicate the issue that does not rely on any accounts: compile v.5.69.0 or any newer version of https://github.com/hashicorp/terraform-provider-aws with golang v1.23 for Darwin-amd64, and just run the compiled binary multiple times on Apple Silicon Macs. It hangs quite reliably, every few other runs.