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/aws@6.42.0
- 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.
Comment From: gabyhelp
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: seankhliao
Why are you using an amd64 binary when an arm64 one is available?
Comment From: 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.
Comment From: 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).
Comment From: 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!
Comment From: 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.
Comment From: 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.
Comment From: rhysh
Thanks @nina-nee . I can reproduce this with
M1 MacBook Air
macOS 14.5
https://github.com/hashicorp/terraform-provider-aws at v5.69.0
go1.23.12 with GOOS=darwin GOARCH=amd64
and with
M1 MacBook Air
macOS 14.5
https://github.com/hashicorp/terraform-provider-aws at v6.10.0
go1.24.6 with GOOS=darwin GOARCH=amd64
It seems to be related to async preemption (as seen in #42700).
$ GODEBUG=asyncpreemptoff=1 stress -timeout=10s -ignore="This binary is a plugin" /tmp/tfaws6.10.0
...
4m10s: 3200 runs so far, 0 failures, 8 active
$ GODEBUG=asyncpreemptoff=0 stress -timeout=10s -ignore="This binary is a plugin" /tmp/tfaws6.10.0
...
15m5s: 600 runs so far, 351 failures (58.50%), 8 active
/var/folders/pw/d_qmtcrd3vs0890gvmrq8qx80000gn/T/go-stress-20250826T212714-3318521547
assertion failed [arm_interval().contains(address)]: code fragment does not contain the given arm address
(CodeFragmentMetadata.cpp:48 instruction_extents_for_arm_address)
ERROR: signal: killed
15m10s: 601 runs so far, 352 failures (58.57%), 8 active
The failures I've seen all include that error (but fail at varying points in the program's startup procedure).
$ shasum -a 256 /var/folders/pw/d_qmtcrd3vs0890gvmrq8qx80000gn/T/go-stress-20250826T212714-* | sort | awk '{if ($1!=prev) {print $2;prev=$1}}' | xargs cat
Starting github.com/hashicorp/terraform-provider-aws@dev (go1.24.6)...
Creating Terraform AWS Provider (SDKv2-style)...
assertion failed [arm_interval().contains(address)]: code fragment does not contain the given arm address
(CodeFragmentMetadata.cpp:48 instruction_extents_for_arm_address)
ERROR: signal: killed
Starting github.com/hashicorp/terraform-provider-aws@dev (go1.24.6)...
Creating Terraform AWS Provider (SDKv2-style)...
Initializing Terraform AWS Provider (SDKv2-style)...
assertion failed [arm_interval().contains(address)]: code fragment does not contain the given arm address
(CodeFragmentMetadata.cpp:48 instruction_extents_for_arm_address)
ERROR: signal: killed
Starting github.com/hashicorp/terraform-provider-aws@dev (go1.24.6)...
Creating Terraform AWS Provider (SDKv2-style)...
Initializing Terraform AWS Provider (SDKv2-style)...
Creating Terraform AWS Provider (Framework-style)...
assertion failed [arm_interval().contains(address)]: code fragment does not contain the given arm address
(CodeFragmentMetadata.cpp:48 instruction_extents_for_arm_address)
ERROR: signal: killed
assertion failed [arm_interval().contains(address)]: code fragment does not contain the given arm address
(CodeFragmentMetadata.cpp:48 instruction_extents_for_arm_address)
ERROR: signal: killed
@mknyszek or @cherrymui , what more do we need before looping in the macOS folks who solved #42700?