SIGSEGV/SIGBUS/other error when running amd64 Java images on arm64 M1 and M2 Macs upgraded to Sonoma #7006
Comments
|
Exactly same behaviour on my end after updating to Sonoma in my Apple M1 Pro 16GB. Amd64 images that run Java 8/11 processes as CMD started to throw same error: Other images such Docker version 24.0.6, build ed223bc |
|
I am also facing this issue after updating to Sonoma on my Apple M1 Pro 32GB. I have an Amd64 image running Java 11 which throws the below error. Interestingly, this error goes away if I uncheck the "Use Rosetta for x86/amd64 Emulation on Apple Silicon" checkbox, but unfortunately, in my case, unchecking this option makes the container run far too slowly. Docker Desktop 4.24.0 (122432) |
|
I'm having the same issue but found a workaround for this, it seems a bit slower but at least it works again. I added an additional argument I hope there will be a solution for this. I'm happy it all works but the performance in some parts of my application is still way slower than it was on my previous Intel based machine. |
|
Same problem here on my M2 Pro 32GB after Sonoma upgrade. I'm running different docker images with java support using rosetta2 (they are all amd64 based images). Not sure if it's related but I see a bad number of reported cores allocated for the containers as well (at the top of the Containers view). I've allocated 4 cores but CPU usage reports: (5 cores allocated). Problem seems to be worse when allocating more cores for the containers. |
|
Same issues on my M1 16GB after Sonoma upgrade. The errors seem to occur on startup for just about any Java-based image. example: Like others I also noticed that the error summary seems to assume one more core than I've actually allocated: Notice the 11 cores. I actually have 10:
Docker Desktop v4.24.0 |
|
Update: I'm not sure if this is a generalizable workaround for others, but in Docker Desktop under Features in development -> Beta features, unchecking |
|
In my case when I uncheck
And docker container stops. |
|
Same problem here. In our company we asked to stop updating to macOS 14 until there is a solution, since we are using Docker containers with Java images. |
|
Guess I'll revert my OS until there's a fix? I'm on the same boat that when I uncheck Rosetta, the container doesn't fully start. |
|
I'll give it a couple of weeks more, waiting for Sonoma 14.1 version; nevertheless no mention about this issue there so far... |
|
Has anyone raised a ticket with Apple about this? If so, do you have a ticket number? |
|
Same problem here with a container with Java 17 and Sonoma 14.0. |
|
We're experiencing the same issue on a couple M1 Macs updated to Sonoma 14.0. I tried 14.1 Beta 3 and have the same issue, unfortunately. |
|
There does seem to be something fishy going on with CPU handling, like @ndobb the setting is set as 8: But when running the CPUS are showing as 900% (i.e. 9): I've noticed it will consistently allocate it an extra core (not sure if I am misinterpretting this setting) but there does seem to be an interesting behaviour here. We have noticed this SEGV issue in containers running multiple Java versions across different distros. |
|
Having the same issue, now with "Use Rosetta vor x86/x64 emulation" on docker won't start up at all. But now I've got it so that at least it starts. it just stakes about 15 minutes... |
|
Limiting cpu ressources to one CPU is fixing the problem for me |
|
Have you tried rolling back to Docker Desktop 4.23? Does the problem occur there as well? |
With Rosetta and 8 CPU cores: With Rosetta and 1 CPU: No error, build is successful. Docker Desktop 4.24.2 (124339) |
Rosetta and 1 CPU "fixed" this for me as well. Mac M1 Pro - Docker Desktop 4.24.0 (122432) |
|
This is caused by a bug in Rosetta and we've reported to Apple. Until a fix is released, and as workaround, please try the parameter Example: |
|
@bsousaa is it possible to somehow use this with |
This worked for my team as well. Thanks @dgageot ! |
|
this seems related buy jvm crashing when i do docker buildx build --platform=linux/amd64 where the dockerfile contains gradlew specifically. m3 max, docker version 4.31.0 this seems relevant as downgrading to 4.27.2 also solved my problem. surprisingly worked for m1 max |
Solves this issue for me as well, thanks! |
restarting macbook helped, thanks. EDIT: |
|
Yes 4.32 seems to have solved the issue for me as well running rosetta2 emulated amd64 java based pods |
|
FINALLY! When will the be officially released? |
This version takes care of business and resolves this issue for us! |
|
I installed it replacing 4.31, but now it's not showing any of my images or containers. Error (macbook M2)Update... after fully uninstalling docker (bug button) and reinstalling the internal Build, all has been running stable for the past week. |
This solved my problem completely. No more JVM Seg Fault. Yay. It is slightly slower it seems than before, but it works, which is better than the alternative!
According to MacRumors, Docker Desktop's Rosetta integration is completely broken in Sequoia. The build in this thread may fix that. Grain of salt. |
|
This also worked for me. When is this version officially going to be
released?
…On Thu, Jun 20, 2024 at 11:34 AM daer-o ***@***.***> wrote:
Hi everyone, here's an internal build that you could try: Docker.dmg
<https://desktop-stage.docker.com/mac/main/arm64/153994/Docker.dmg> We
believe it fixes your issues. I would be happy to find out if it does.
This solved my problem completely. No more JVM Seg Fault. Yay. It is
slightly slower it seems than before, but it works, which is better than
the alternative!
—
Reply to this email directly, view it on GitHub
<#7006 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADBB6KXYP7TL4CVSUTP6SQTZIMOENAVCNFSM6AAAAAA5QD6MKWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBRGMYDAMRVGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Arvind
+1-408-922-9072
|
|
@dgageot Any ideas on the ETA for this in GA? |
|
This is interesting, I was on Sonoma 14.5 and upgraded to 4.31.1 and no I cannot start docker at all on my M2. I'm not sure what version of docker I was running before. |
@dgageot tried unpacking and installing the linked release. Now Docker Desktop won't start. Restarted my mac and reinstalled multiple times. When booting up 'Docker Desktop' it gets stuck on the initial loading screen. 'Starting Docker Engine' or similar. I'm installing the standard release now and hoping it will boot up. EDIT: reinstalling the current base release worked fine. EDIT2: After installing the standard release, removing it, and then installing the relase you mentioend in your post, Docker was able to start. However like others mentioned, all saved images are lost. EDIT3: Currently on the release provided in this thread. Unable to run any containers or build any images. On Docker Desktop it only displays 'An error occurred while loading the images list'. |
Fixed for me here |
|
Any idea of when this fix will be available in the stable package? |
|
Docker Desktop 4.32 should be out early this week. |
|
A fix has been issued for this in the latest Docker Desktop 4.32.0, see https://docs.docker.com/desktop/release-notes/ If the issue persists, don't hesitate to reach out! |
This bug seem to affect me as well on lima without docker desktop. Do you have any pointers on what has been updated to fix the issue. |
|
The latest version(4.32) solved the issue. |
The issue still persist after upgrading to 4.32 with the same callstack. |
|
Got the same error after Sonoma upgrade on Mac M2 Max 32Gb, solved by updating Docker desktop to 4.32.0 (157355) |
|
4.32 also fixed my issues on Mac M3 Max |
Seems don't solve yet |
Yes, it worked great for me too! |
Any pointers? |
Me 2!!!!! Thanks! |
and others
Description
I have been getting strange SIGSEGV/SIGBUS errors when running certain images. Can't tell if it is a bug in Rosetta Sonoma or Docker.
Commonalities between all images that get the same error:
linux/amd64images running onlinux/arm64with the "Use Rosetta for x86/amd64 emulation on Apple Silicon" option checkedI've seen SIGSEGV errors (most common) as well as a few SIGBUS and more generic but out-of-place Java errors.
I was able to replicate it with an old public Cassandra image, but it takes multiple tries (around 4 or 5). The 64GB M1 Pro Max seemed to crash more reliably than the same command on the 8GB M2. There might be another application that more reliably crashes, particularly ones that are very memory hungry.
Output of full log with error is in additional information.
Related error in adoptium issues: adoptium/adoptium-support#904
Reproduce
docker run -it --rm --name cass-3.11 --platform linux/amd64 cassandra:3.11Also crashes:
docker run -it --rm --name jenkins --platform linux/amd64 jenkins/jenkinsExpected behavior
Image should behave like the
arm64variant; image should start successfully.Successful command:
Log of successful (arm64) output is in additional information.
docker version
Client: Docker Engine - Community Version: 24.0.6 API version: 1.43 Go version: go1.21.0 Git commit: ed223bc820 Built: Thu Aug 31 17:24:32 2023 OS/Arch: darwin/arm64 Context: desktop-linux Server: Docker Desktop 4.24.0 (122432) Engine: Version: 24.0.6 API version: 1.43 (minimum version 1.12) Go version: go1.20.7 Git commit: 1a79695 Built: Mon Sep 4 12:31:36 2023 OS/Arch: linux/arm64 Experimental: false containerd: Version: 1.6.22 GitCommit: 8165feabfdfe38c65b599c4993d227328c231fca runc: Version: 1.1.8 GitCommit: v1.1.8-0-g82f18fe docker-init: Version: 0.19.0 GitCommit: de40ad0docker info
Diagnostics ID
AA9BC4C0-C4EB-412B-9A43-91744219A5ED/20231002230347
Additional Info
Log of output with error:
Log of output without error:
Jenkins crash:
The text was updated successfully, but these errors were encountered: