Closed patthomasrick closed 2 months ago
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:
*************************************************************
*************************************************************
*************************************************************
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007ffffea61b81, pid=7, tid=53
#
# JRE version: OpenJDK Runtime Environment Temurin-11.0.20.1+1 (11.0.20.1+1) (build 11.0.20.1+1)
# Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.20.1+1 (11.0.20.1+1, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x661b81] oopDesc::size_given_klass(Klass*)+0x1
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/hs_err_pid7.log
#
# If you would like to submit a bug report, please visit:
# https://github.com/adoptium/adoptium-support/issues
#
Other images such docker.elastic.co/elasticsearch/elasticsearch:8.10.2
which runs java under the hood fail on start-up:
Exception in thread "main" java.io.UncheckedIOException: java.io.IOException: Cannot run program "/usr/share/elasticsearch/jdk/bin/java": error=0, Failed to exec spawn helper: pid: 38, exit value: 1
at org.elasticsearch.server.cli.ServerProcess.start(ServerProcess.java:119)
at org.elasticsearch.server.cli.ServerProcess.start(ServerProcess.java:88)
at org.elasticsearch.server.cli.ServerCli.startServer(ServerCli.java:239)
at org.elasticsearch.server.cli.ServerCli.execute(ServerCli.java:100)
at org.elasticsearch.common.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:54)
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:85)
at org.elasticsearch.cli.Command.main(Command.java:50)
Docker version 24.0.6, build ed223bc Docker Compose version v2.22.0-desktop.2
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.
#2023-10-03 13:29:12 # A fatal error has been detected by the Java Runtime Environment:
2023-10-03 13:29:12 #
2023-10-03 13:29:12 # SIGSEGV (0xb) at pc=0x00007ffffe439800, pid=252, tid=256
2023-10-03 13:29:12 #
2023-10-03 13:29:12 # JRE version: OpenJDK Runtime Environment 18.9 (11.0.8+10) (build 11.0.8+10-LTS)
2023-10-03 13:29:12 # Java VM: OpenJDK 64-Bit Server VM 18.9 (11.0.8+10-LTS, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
2023-10-03 13:29:12 # Problematic frame:
2023-10-03 13:29:12 # V [libjvm.so+0x7d0800] void OopOopIterateBoundedDispatch<G1AdjustClosure>::Table::oop_oop_iterate_bounded<InstanceMirrorKlass, unsigned int>(G1AdjustClosure*, oopDesc*, Klass*, MemRegion)+0x40
2023-10-03 13:29:12 #
2023-10-03 13:29:12 # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
2023-10-03 13:29:12 #
2023-10-03 13:29:12 # An error report file with more information is saved as:
2023-10-03 13:29:12 # /opt/jboss/wildfly/bin/hs_err_pid252.log
2023-10-03 13:29:12 #
2023-10-03 13:29:12 # If you would like to submit a bug report, please visit:
2023-10-03 13:29:12 # https://bugreport.java.com/bugreport/crash.jsp
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
vmargs= -XX:+UseZGC
This prevents the cash most of the times, however I have still seen it a few times.
I hope there will be a solution for this.
the other additional agruent I have to use from the start Rosetta was supported in docker is this one: -Djdk.lang.Process.launchMechanism=vfork
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). Getting errors like the one below pretty much on every app startup.
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).
2023-10-03 14:14:42 weblogic | #
2023-10-03 14:14:42 weblogic | # A fatal error has been detected by the Java Runtime Environment:
2023-10-03 14:14:42 weblogic | #
2023-10-03 14:14:42 weblogic | # [thread 140737461089856 also had an error]
2023-10-03 14:14:42 weblogic | SIGSEGV (0xb) at pc=0x00007fffff2b5090, pid=50, tid=0x00007ffffe1ff640
2023-10-03 14:14:42 weblogic | #
2023-10-03 14:14:42 weblogic | # JRE version: Java(TM) SE Runtime Environment (7.0_311-b07) (build 1.7.0_311-b07)
2023-10-03 14:14:42 weblogic | # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.311-b07 mixed mode linux-amd64 compressed oops)
2023-10-03 14:14:42 weblogic | # Problematic frame:
2023-10-03 14:14:42 weblogic | # V [libjvm.so+0x8b5090] StealTask::do_it(GCTaskManager*, unsigned int)+0x220
2023-10-03 14:14:42 weblogic | #
2023-10-03 14:14:42 weblogic | # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
2023-10-03 14:14:42 weblogic | #
2023-10-03 14:14:42 weblogic | # An error report file with more information is saved as:
2023-10-03 14:14:42 weblogic | # /opt/oracle/domain/hs_err_pid50.log
2023-10-03 14:14:42 weblogic | #
2023-10-03 14:14:42 weblogic | # If you would like to submit a bug report, please visit:
2023-10-03 14:14:42 weblogic | # http://bugreport.java.com/bugreport/crash.jsp
2023-10-03 14:14:42 weblogic | #
2023-10-03 14:14:42 weblogic | Aborted
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:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007ffffe3ac734, pid=109, tid=155
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13-LTS)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13-LTS, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x7e5734]
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
Like others I also noticed that the error summary seems to assume one more core than I've actually allocated:
--------------- S U M M A R Y ------------
Command Line: -D[Standalone] -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED -Dorg.jboss.boot.log.file=/opt/jboss/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/jboss/wildfly/standalone/configuration/logging.properties /opt/jboss/wildfly/jboss-modules.jar -mp /opt/jboss/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/jboss/wildfly -Djboss.server.base.dir=/opt/jboss/wildfly/standalone -b 0.0.0.0 -c standalone.xml -Djboss.http.port=8080
Host: x86_64, 11 cores, 11G, CentOS Linux release 7.6.1810 (Core)
Notice the 11 cores. I actually have 10:
Docker Desktop v4.24.0 Docker version 24.0.6, build ed223bc Docker Compose version v2.22.0-desktop.2
@ndobb extra cores issue also reported here. https://github.com/docker/for-mac/issues/7010
Update: I'm not sure if this is a generalizable workaround for others, but in Docker Desktop under Features in development -> Beta features, unchecking Use Rosetta for x86/amd64 emulation on Apple Silicon
seems to at least prevent the Java-based containers from going down on startup for me.
In my case when I uncheck Use Rosetta for x86/amd64 emulation on Apple Silicon
I would get:
qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault
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?
Limiting cpu ressources to one CPU is fixing the problem for me
With Rosetta and 8 CPU cores:
12.29 #
12.29 # A fatal error has been detected by the Java Runtime Environment:
12.29 #
12.29 # SIGSEGV (0xb) at pc=0x00007fffff196e4f, pid=1, tid=43
12.29 #
12.29 # JRE version: OpenJDK Runtime Environment Corretto-17.0.8.8.1 (17.0.8.1+8) (build 17.0.8.1+8-LTS)
12.29 # Java VM: OpenJDK 64-Bit Server VM Corretto-17.0.8.8.1 (17.0.8.1+8-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
12.29 # Problematic frame:
12.29 # V [libjvm.so+0x738e4f] G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x355f
12.30 #
12.30 # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
12.30 #
12.30 # An error report file with more information is saved as:
12.30 # /usr/app/hs_err_pid1.log
12.32 #
12.32 # If you would like to submit a bug report, please visit:
12.32 # https://github.com/corretto/corretto-17/issues/
12.32 #
12.32
12.32 [error occurred during error reporting (), id 0xb, SIGSEGV (0xb) at pc=0x00007fffffdbb898]
With Rosetta and 1 CPU: No error, build is successful.
Docker Desktop 4.24.2 (124339)
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 --env JAVA_OPTS="-XX:-UseG1GC -XX:+UseZGC"
in your docker run
command.
Example: docker run -it --rm --name jenkins --platform linux/amd64 jenkins/jenkins --env JAVA_OPTS="-XX:-UseG1GC -XX:+UseZGC
@bsousaa is it possible to somehow use this with docker compose
? I couldn't make it work (I mean setting the parameter --env JAVA_OPTS="-XX:-UseG1GC -XX:+UseZGC"
)
Thank you @bsousaa for your update.
Those options are for more recent JVMs.
Do you have any advice for users of Java earlier than 15 who are NOT using G1?
Thank you @bsousaa for your update.
Those options are for more recent JVMs.
- G1GC is being turned off here, it is more of a Java 9+ technology, so for those users of Java 8, you may want to turn it off in this way just to be sure, but it may not be on in the first place.
- ZGC is available for Java versions 15+.
Do you have any advice for users of Java earlier than 15 who are NOT using G1?
Modifying cpu ressources to 1 cpu fixed the problem for me without using the JAVA_OPTS maybe try this.
I have spoken to some people for whom 1 CPU does not work.
@bsousaa is the bug with Apple publicly viewable and, if so, could we have a link please?
Do you have any advice for users of Java earlier than 15 who are NOT using G1?
I'm not a Java expert but my advice would be to try and see what different GCs exist for your version of the JVM and try them out.
I am curious though, do people see the same error with Java 8 for example? Could someone give us the error they get on older JVMs?
@bsousaa is it possible to somehow use this with
docker compose
? I couldn't make it work (I mean setting the parameter--env JAVA_OPTS="-XX:-UseG1GC -XX:+UseZGC"
)
Hello @dbulaj,
There are different possibilities to setup an env variables with Compose, you can just use a simple -e
attribute like this docker compose up -e JAVA_OPTS="-XX:-UseG1GC -XX:+UseZGC"
or you can use env-file, environment attribute in the compose file...
You could see all the available options here
I am curious though, do people see the same error with Java 8 for example? Could someone give us the error they get on older JVMs?
We have to use Java 8 for our service which runs inside of a docker container. I get a similar error while trying to run it (build step inside of a docker container):
> [service-name build 11/16] RUN mvn -s ./maven_settings.xml -f ./pom.xml -B de.qaware.maven:go-offline-maven-plugin:1.2.8:resolve-dependencies:
1.994 #
1.995 # A fatal error has been detected by the Java Runtime Environment:
1.995 #
1.995 # SIGSEGV (0xb) at pc=0x00007ffffed1ca00, pid=7, tid=0x00007ffffc209700
1.997 #
1.998 # JRE version: OpenJDK Runtime Environment (Zulu 8.50.0.51-CA-linux64) (8.0_275-b01) (build 1.8.0_275-b01)
2.009 # Java VM: OpenJDK 64-Bit Server VM (25.275-b01 mixed mode linux-amd64 compressed oops)
2.009 # Problematic frame:
2.009 # V [libjvm.so+0x99fa00] StealTask::do_it(GCTaskManager*, unsigned int)+0x230
2.031 #
2.031 # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
2.031 #
2.032 # An error report file with more information is saved as:
2.032 # /usr/src/app/hs_err_pid7.log
2.051 #
2.051 # If you would like to submit a bug report, please visit:
2.051 # http://www.azulsystems.com/support/
2.051 #
2.059 Aborted
Client:
Cloud integration: v1.0.35+desktop.5
Version: 24.0.6
API version: 1.43
Go version: go1.20.7
Git commit: ed223bc
Built: Mon Sep 4 12:28:49 2023
OS/Arch: darwin/arm64
Context: desktop-linux
Server: Docker Desktop 4.24.2 (124339)
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: de40ad0
Client:
Version: 24.0.6
Context: desktop-linux
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.11.2-desktop.5
Path: /Users/USER/.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.22.0-desktop.2
Path: /Users/USER/.docker/cli-plugins/docker-compose
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.0
Path: /Users/USER/.docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.20
Path: /Users/USER/.docker/cli-plugins/docker-extension
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v0.1.0-beta.8
Path: /Users/USER/.docker/cli-plugins/docker-init
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /Users/USER/.docker/cli-plugins/docker-sbom
scan: Docker Scan (Docker Inc.)
Version: v0.26.0
Path: /Users/USER/.docker/cli-plugins/docker-scan
scout: Docker Scout (Docker Inc.)
Version: v1.0.7
Path: /Users/USER/.docker/cli-plugins/docker-scout
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 5
Server Version: 24.0.6
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 8165feabfdfe38c65b599c4993d227328c231fca
runc version: v1.1.8-0-g82f18fe
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
cgroupns
Kernel Version: 6.4.16-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: aarch64
CPUs: 10
Total Memory: 7.667GiB
Name: docker-desktop
ID: 156b61f9-0d2e-483e-a0a3-a659cfafbb09
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false
@flying7eleven could you try with -XX:+UseSerialGC
in your build step? Another GC available in Java 8 is -XX:+UseConcMarkSweepGC
We see the issue with Java 8 too, I have tried all available GCs available and none seemed to work - they all fail in similar ways.
G1GC:
# SIGSEGV (0xb) at pc=....., pid=....., tid=....
#
# JRE version: Java(TM) SE Runtime Environment (8.0_202-b08) (build 1.8.0_202-b08)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V [libjvm.so+0x645027] InstanceKlass::oop_follow_contents(ParCompactionManager*, oopDesc*)+0x397
ConcMarkSweepGC/Serial:
SIGSEGV (0xb) at pc=....., pid=..., tid=....
#
# JRE version: Java(TM) SE Runtime Environment (8.0_202-b08) (build 1.8.0_202-b08)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V [libjvm.so+0x987652] oopDesc* PSPromotionManager::copy_to_survivor_space<false>(oopDesc*)+0x3b2
ConcMarkSweepGC appeared to get further than the others. I think the errors are not necessarily specific to the GC algorithm necessarily.
@rumpl I tried both options separately as well as together. Unfortunately, no option helped. In both cases I get the same error as stated above. The problematic frame - where the SEGFAULT occurs is changing for each run:
V [libjvm.so+0x919a07] ServiceUtil::visible_oop(oopDesc*)+0x77
V [libjvm.so+0x99bd73] oopDesc* PSPromotionManager::copy_to_survivor_space<false>(oopDesc*)+0xf3
V [libjvm.so+0x916ecf] ObjectMonitor::enter(Thread*)+0x3f
I think the errors are not necessarily specific to the GC algorithm necessarily.
It would appear so yes, the issue is not which GC is used, the issue is a bug in Rosetta that I think corrupts the memory, so it's a game of finding the best GC that knows how to handle faulty (virtual) hardware :)
@JoelClemence What about trying out ConcMarkSweepGC
but setting also setting -XX:ParallelGCThreads=1
I just tested and for example docker run --rm -it -platform linux/amd64 -e JAVA_OPTS="-XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=1" jenkins/jenkins:lts-jdk8
works
Unfortunately cannot reproduce - I'm still getting SEGV with the same Java Opts.
we are facting the same issue here. reducing the CPU to 1 - as @bfrcpz mentioned - works as a workaround. but does not fix the actual issue.
Same issue on M2 Sonoma, resolved the issue by changing the CPU limit to 2
Same issue on M2 Sonoma, resolved the issue by changing the CPU limit to 2
I have set the CPU limit to 4 in Docker and I'm not facing an issue.
I have set the CPU limit to 4 in Docker and I'm not facing an issue.
I can confirm that it works on my end, too, with 4
cores.
Version 14.1 (23B73)
I'm using confluentinc/cp-kafka:5.5.4
image on M1 Max with Docker 4.24.2 and turned on Use Rosetta for x86/amd64 emulation on Apple Silicon
and changing CPU to 1, 2, 4 or any other value has no effect. Still getting
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (nmethod.cpp:2659), pid=1, tid=0x00007fffc0bef700
# guarantee(nm->_lock_count >= 0) failed: unmatched nmethod lock/unlock
#
# JRE version: OpenJDK Runtime Environment (Zulu 8.40.0.25-CA-linux64) (8.0_222-b10) (build 1.8.0_222-b10)
# Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/hs_err_pid1.log
[thread 140737455724288 also had an error]
#
# If you would like to submit a bug report, please visit:
# http://www.azulsystems.com/support/
#
Any suggestion / help wold be greatly appreciated.
@dbulaj , what MacOS
version are you using? I just tried now on Version 14.1 (23B73)
and it worked.
@GarryOne I'm on 14.0 (23A344). I guess 14.1 is RC now and should hit public audience in upcoming weeks, right? Glad to hear it works. Thanks for checking
i'm still on 14.0 and it works with 4 cores. If I set a value above 4 cores I get the same error though.
can somebody on 14.1 try to set the cores to more than 4 and confirm that it has been fixed?
On 14.1 I am having success with up to 11 cores.
Closing this as resolved, as the issue has been fixed in the latest release of macOS Sonoma, 14.1
For the benefit of anyone who is wondering why the "Use Rosetta for x86/amd64" setting isn't showing up where everybody says it should be, it has been moved out of experimental section of the settings to the "General" section in the more recent versions of Docker Desktop. Make sure that it is turned on.
parece ser que con la ultima actualizacion de sonoma queda el problema resuelto
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/amd64
images running onlinux/arm64
with 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: https://github.com/adoptium/adoptium-support/issues/904
Reproduce
docker run -it --rm --name cass-3.11 --platform linux/amd64 cassandra:3.11
Also crashes:
docker run -it --rm --name jenkins --platform linux/amd64 jenkins/jenkins
Expected behavior
Image should behave like the
arm64
variant; image should start successfully.Successful command:
Log of successful (arm64) output is in additional information.
docker version
docker info
Diagnostics ID
AA9BC4C0-C4EB-412B-9A43-91744219A5ED/20231002230347
Additional Info
Log of output with error:
Log of output without error:
Jenkins crash: