Floating point values are truncated when run on M1 with Rosetta x86_64 emulation (via Docker)

[RobinMalfait]

What version of Bun is running?

1.2.13+64ed68c9e

What platform is your computer?

Darwin 24.4.0 arm64 arm

What steps can reproduce the bug?

If you run the following script, then the first docker run which uses linux/x86_64 will produce truncated values. Only on M1, running this on an M4 does work as expected.

The second docker run which uses linux/arm64 also works as expected.

#!/usr/bin/env bash

cat > repro.sh <<EOF
#!/usr/bin/env bash

curl -fsSL https://bun.sh/install | bash

~/.bun/bin/bun --print '[0.25, Number("0.25")]'
EOF

chmod +x repro.sh

# [ 0, 0 ]
docker run --mount=type=bind,source=$(pwd),target=/repro -w /repro --platform=linux/x86_64 node:24 ./repro.sh

# [ 0.25, 0.25 ]
docker run --mount=type=bind,source=$(pwd),target=/repro -w /repro --platform=linux/arm64 node:24 ./repro.sh

Running the same setup using node, then it works in both cases:

#!/usr/bin/env bash

cat > repro.sh <<EOF
#!/usr/bin/env bash

node -e 'console.log([0.25, Number("0.25")])'
EOF

chmod +x repro.sh

# [ 0.25, 0.25 ]
docker run --mount=type=bind,source=$(pwd),target=/repro -w /repro --platform=linux/x86_64 node:24 ./repro.sh

# [ 0.25, 0.25 ]
docker run --mount=type=bind,source=$(pwd),target=/repro -w /repro --platform=linux/arm64 node:24 ./repro.sh

What is the expected behavior?

When using floating point numbers such as 0.25 or 1.25 I expect them to to stay as-is, instead of being truncated to just 0 and 1 respectively.

What do you see instead?

Floating point numbers such as 0.25 and 1.25 get truncated to just 0 and 1 respectively.

Additional information

It also looks like this behavior happens in cases such as:

Number('1.25')      // 1
parseFloat('1.25')  // 1
1 / 4               // 0

Other fun observation:

In Docker Desktop, if you uncheck the Use Rosetta for x86_64/amd64 emulation on Apple Silicon option, or switch to Docker VMM or switch to QEMU (Legacy) then it will work as expected.

But the moment you use Apple Virtualization framework with the Use Rosetta for x86_64/amd64 emulation on Apple Silicon checked, then it will fail.

Edit: also tested this on an M1 Mac mini and it also reproduces there.

[190n]

Interesting. I've tried on two systems:

• M1 Max, macOS 15.3.2 (older than yours), Docker Desktop 4.40.0 (187762)
• M3 Max, macOS 15.4.0 (same as yours), same Docker version as above

and I couldn't see this issue on either one. I'm curious:

• What Docker version do you have?
• Do you remember if this used to work (with older Bun versions, older macOS versions, older Docker, or anything else)?

It's honestly hard for me to see this not being a Rosetta bug, since Bun does work on real x86_64 CPUs (and in QEMU), but it might be something we could work around. The fact that it doesn't repro on an M1 Max with older macOS suggests it might have just broken in the latest macOS release, but I can't really be sure. We'll try updating the M1 Max system when we have a bit more time.

[RobinMalfait]

Yeah good question, I never use Docker myself so can't answer these questions unfortunately. We just had some bug reports that Tailwind CSS standalone CLIs (which uses bun behind the scenes) didn't work as expected.

This morning I did update my OS to 15.5 (24F74) and now the bug is gone as well.

I agree that this is very likely a Rosetta bug, but the reason I opened the issue here is because we didn't see this behavior when using Node.js.

I don't even know if you can workaround it or not, just wanted to make you guys aware in case somebody else runs into the issue.

So in summary, if you:

• Update your macOS version
• Or don't use Rosetta
• Or use Docker VMM
• Or use the legacy QEMU

then it starts working 😅

[190n]

This morning I did update my OS to 15.5 (24F74) and now the bug is gone as well.

That's so weird, because my coworker's M1 Max does now demonstrate this bug after upgrading from 15.3 to 15.5. 🙃

Will investigate a little further...