Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Docker Desktop for Mac] - Support for running x86-64 binaries with Rosetta 2 #384

Open
christophermclellan opened this issue Jul 1, 2022 · 196 comments
Assignees
Labels
docker_desktop Improvements or additions to Docker Desktop

Comments

@christophermclellan
Copy link
Collaborator

Tell us about your request
Support Rosetta 2 for running x86-64 Linux binaries on Apple Silicon

Which service(s) is this request for?
Docker Desktop for Mac

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Ensure that users can run their Intel-based workloads on Apple Silicon, using Rosetta 2

Are you currently working around the issue?
Docker Desktop users can currently use QEMU for this

@thisisthekap
Copy link

@christophermclellan With this feature, we should be able to use Microsoft SQL server for Linux on M1. This would be awesome!

@darrinholst
Copy link

we should be able to use Microsoft SQL server for Linux on M1

If this is true you're going to make many long-suffering mssql users very happy. Very much looking forward to this.

Due to the presumed qemu "issue" there is actually no workaround for running that image on arm64. (yes, I know about colima. no, it's not a viable workaround)

@thisisthekap
Copy link

@christophermclellan Are you able to provide some more detail on the plans for implementing this feature?

@arsereg
Copy link

arsereg commented Aug 17, 2022

@christophermclellan This would allow us to use Java Temurin images. Currently, they have been investing lots of time figuring out how to build images for m1, and it doesn't seem this will be solved anytime soon.

Multiple other services would work amazingly, like Payara or MSSQL

@boboldehampsink
Copy link

Another use case for running Intel on Rosetta 2 over a native amd64 image is because of dev/prod parity with the server for example - see heroku/base-images#194

@thisisthekap
Copy link

@christophermclellan Are you able to provide a timeline describing when this feature is going to be implemented?

@diogonborges
Copy link

Any development here? Ball-park timeline for this?

@konstantinos-kafkas-cko

Please add support for Apple M1 silicon.

@christophermclellan
Copy link
Collaborator Author

Hi folks, please excuse my delay regarding timelines. So, right now we are focussing on getting virtiofs implemented as the default file sharing mechanism on Mac, we're very close on this one. Once complete, we'll immediately turn attention to Rosetta. I'm not able to disclose precise timelines, but...soon !

@joostvanvucht
Copy link

joostvanvucht commented Sep 16, 2022

rosetta seems to works quite well, tested using ventura, utm 4.04 beta & manual docker setup on macbook m1 air

root@ub1:~# uname -a
Linux ub1 5.15.0-47-generic #51-Ubuntu SMP Fri Aug 12 08:18:32 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

root@ub1:~# mount | grep rose
rosetta on /mnt/rosetta type virtiofs (rw,relatime)

root@ub1:~# ps -ef | grep rose
2001 5803 2728 1 14:28 ? 00:00:42 /mnt/rosetta/rosetta /opt/tibco/ftl/6.6/bin/tibftlserver -c /config/ftl.yaml -n ftlserver-0
2001 5882 5803 3 14:28 ? 00:01:32 /mnt/rosetta/rosetta /opt/tibco/ftl/6.6/bin/tibmux --realmserver http://127.0.0.1:30080 --client-label ftl.ftlserver-0 --external-address [email protected]:30080 --bind-address *:30080 --peer-muxes [email protected]:30080 --trace warn
2001 5983 5803 42 14:28 ? 00:18:50 /mnt/rosetta/rosetta /opt/tibco/ftl/6.6/bin/tibrserver --server.label realm.ftlserver-0 --data /data/ftlserver_0_data --http 127.0.0.1:0 --ftl ftlserver-0.ftlservers:30083 --gui 127.0.0.1:0 --client.url http://127.0.0.1:30080 --ftlserver.urls [email protected]:30080 --ftlserver.name ftlserver-0
1001 6187 4686 2 14:28 ? 00:00:56 /mnt/rosetta/rosetta /etc/alternatives/jre/bin/java -javaagent:/jmx_prometheus_javaagent-0.16.1.jar=8080:/opt/config/config.yaml -Djava.util.logging.config.file=logging.properties -Djava.security.auth.login.config=/opt/activemq/conf/login.config -Dcom.sun.management.jmxremote -Djava.awt.headless=true -Djava.io.tmpdir=/opt/apache-activemq-5.15.2//tmp -Dactivemq.classpath=/opt/apache-activemq-5.15.2//conf:/opt/apache-activemq-5.15.2//../lib/: -Dactivemq.home=/opt/apache-activemq-5.15.2/ -Dactivemq.base=/opt/apache-activemq-5.15.2/ -Dactivemq.conf=/opt/apache-activemq-5.15.2//conf -Dactivemq.data=/opt/apache-activemq-5.15.2//data -jar /opt/apache-activemq-5.15.2//bin/activemq.jar start
2001 6337 5803 2 14:28 ? 00:01:08 /mnt/rosetta/rosetta /opt/tibco/ftl/6.6/bin/tibpserver --name default_ftlserver-0 --data /data/ftlserver_0_data --realmserver http://127.0.0.1:30080
2001 6377 4463 3 14:28 ? 00:01:36 /mnt/rosetta/rosetta /opt/tibco/as/4.7/bin/tibdgkeeper -r http://ftlserver-0.ftlservers:30080 -n keeper-0 -g VirtueleTreinInfoStore
2001 6419 2486 5 14:28 ? 00:02:31 /mnt/rosetta/rosetta /opt/tibco/as/4.7/bin/tibdgproxy -r http://ftlserver-0.ftlservers:30080 -n proxy-0 -g VirtueleTreinInfoStore
2001 6421 3376 0 14:28 ? 00:00:09 /mnt/rosetta/rosetta /opt/tibco/as/4.7/bin/tibdgadmind -r http://ftlserver-0.ftlservers:30080 -l :30081
2001 6734 4895 3 14:28 ? 00:01:24 /mnt/rosetta/rosetta /opt/tibco/as/4.7/bin/tibdgnode -r http://ftlserver-0.ftlservers:30080 -n cs-01-node-0 -g VirtueleTreinInfoStore
joost 7107 3827 0 14:28 ? 00:00:19 /mnt/rosetta/rosetta /opt/tibco/ems/8.6/bin/tibemsd -config /shared/ems/config/emsserver-svc.json
root 7141 3827 0 14:28 ? 00:00:00 /mnt/rosetta/rosetta /usr/bin/sh /runPromCollector.sh
root 7159 7141 0 14:28 ? 00:00:18 /mnt/rosetta/rosetta /usr/bin/java -cp emsStatsLogger.jar:/ems/lib/tibjmsadmin.jar:/ems/lib/jms-2.0.jar:/ems/lib/tibjms.jar EmsStatsPromCollector -config /config/servers.xml -interval 60 -job TIB-EMS-vtlocal -debug -nolog
48 9352 9190 0 14:31 ? 00:00:00 /mnt/rosetta/rosetta /bin/bash /treinviewer/scripts/run.sh
root 9368 9352 0 14:31 ? 00:00:00 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
48 9369 9368 0 14:31 ? 00:00:00 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
48 9370 9368 0 14:31 ? 00:00:02 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
48 9371 9368 0 14:31 ? 00:00:02 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
48 9372 9368 0 14:31 ? 00:00:02 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
48 10480 9368 0 14:35 ? 00:00:03 /mnt/rosetta/rosetta /usr/sbin/httpd -D FOREGROUND
root 13340 13162 0 14:38 ? 00:00:01 /mnt/rosetta/rosetta /usr/bin/sh /wait-for-service.sh
root 17114 16961 0 14:47 ? 00:00:00 /mnt/rosetta/rosetta /usr/bin/sh /wait-for-service.sh
root 17357 17159 0 14:47 ? 00:00:00 /mnt/rosetta/rosetta /usr/bin/sh /wait-for-service.sh
root 17374 17193 0 14:47 ? 00:00:00 /mnt/rosetta/rosetta /usr/bin/sh /wait-for-service.sh
2001 21600 20248 12 14:58 ? 00:01:54 /mnt/rosetta/rosetta /opt/tibco/be/6.0/bin/be-engine --propFile /opt/tibco/be/6.0/bin/be-engine.tra --propVar AS_DISCOVER_URL=tcp://masterdataengine-74c44cd5c7-rg8bx:50000 --propVar AS_LISTEN_URL=tcp://masterdataengine-74c44cd5c7-rg8bx:50000 --propVar jmx_port=5555 -n VTMasterDataEngine -c /opt/tibco/be/application/MasterData.cdd -u VTMasterDataEngine -p beprops_all.props /opt/tibco/be/application/ear/be_masterdata-1.66.0.ear --innerProcess
472 25099 24317 0 15:04 ? 00:00:04 /mnt/rosetta/rosetta /usr/share/grafana/bin/grafana-server --homepath=/usr/share/grafana --config=/etc/grafana/grafana.ini --packaging=docker cfg:default.log.mode=console cfg:default.paths.data=/var/lib/grafana cfg:default.paths.logs=/var/log/grafana cfg:default.paths.plugins=/var/lib/grafana/plugins cfg:default.paths.provisioning=/etc/grafana/provisioning
root 28779 13340 1 15:12 ? 00:00:00 /mnt/rosetta/rosetta /usr/bin/nc -z cacheenginediscoverynode-svc 50000
root 28780 17114 1 15:12 ? 00:00:00 /mnt/rosetta/rosetta /usr/bin/nc -z cacheengine-svc 50000
root 28781 17374 1 15:12 ? 00:00:00 /mnt/rosetta/rosetta /usr/bin/nc -z cacheengine-svc 50000
root 28783 17357 1 15:12 ? 00:00:00 /mnt/rosetta/rosetta /usr/bin/nc -z cacheengine-svc 50000
root 28785 23820 0 15:12 pts/2 00:00:00 grep --color=auto rose

@ianjukes
Copy link

ianjukes commented Sep 17, 2022

Hi folks, please excuse my delay regarding timelines. So, right now we are focussing on getting virtiofs implemented as the default file sharing mechanism on Mac, we're very close on this one. Once complete, we'll immediately turn attention to Rosetta. I'm not able to disclose precise timelines, but...soon !

Thank you @christophermclellan!

@JoeZhongTR
Copy link

I need to dev/run python on a x86_64 docker on M1 Macs. Looking forward to it!

@toxik
Copy link

toxik commented Nov 4, 2022

Hi folks, please excuse my delay regarding timelines. So, right now we are focussing on getting virtiofs implemented as the default file sharing mechanism on Mac, we're very close on this one. Once complete, we'll immediately turn attention to Rosetta. I'm not able to disclose precise timelines, but...soon !

Heya, any news? 😄

@dansitu
Copy link

dansitu commented Nov 9, 2022

This will be a game changer for our team, thank you for your hard work!

@Will-Bill
Copy link

MS SQL on Mac M1 is requested a lot, I think this would solve that issue too.

@kirbyzhou
Copy link

Is there any beta version can try it?

@wowditi
Copy link

wowditi commented Nov 25, 2022

If it helps anyone, when running a fedora 36 VM using UTM with rosetta mounted to /media/rosetta/rosetta the following command allowed docker to use it for x86_64 images

echo ':rosetta-x86_64:M:0:\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x3e\x00:\xff\xff\xff\xff\xff\xfe\xfe\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/media/rosetta/rosetta:CF' > /proc/sys/fs/binfmt_misc/register

@thisisthekap
Copy link

@wowditi Sounds awesome! Are you able to provide some more detail on how to setup & use docker in this scenario?

@wowditi
Copy link

wowditi commented Nov 25, 2022

@thisisthekap start an aarch64 fedora 36 VM (https://getfedora.org/en/workstation/download/) using UTM and enable "Use Apple Virtualization" and "Enable Rosetta". Once the installation is complete install docker according to the instructions (https://docs.docker.com/engine/install/fedora/). Then mount the Rosetta binary as described by the UTM documentation https://docs.getutm.app/advanced/rosetta/. Fedora does not include an "/usr/sbin/update-binfmts" script so instead of that you need to use the above command. Then you should be able to start docker x86_64 images and you can check using "ps" that every command is started with /media/rosetta/rosetta and that the performance is a lot better than qemu-user-static (which is what docker desktop uses).

I tried to get it to work in docker desktop using a simple mount, but I think the problem is that the VM needs to run in a special memory mode which I could not figure out how to do unfortunately.

@agrawroh
Copy link

I'm on M1 (Sonoma 14.1) and Docker Desktop 4.25.1 (128006). I see this error while using --platform linux/amd64:
"rosetta error: bss_size overflow
%"

@djcristi
Copy link

djcristi commented Nov 22, 2023

Thank you all for your patience and support here, for testing new releases and letting us know what worked and what hadn't. As you have noticed, Rosetta is no longer a Beta feature in Docker Desktop.

There have been quite a few issues reported here, and most of them also confirmed here as fixed in Sonoma. The most recent issue, the SIGSEGV/SIGBUS error when running Java images, docker/for-mac#7006, has also been fixed in the latest Sonoma version, 14.1.

We will close this roadmap issue soon, but if you encounter any more problems with Rosetta, please let us know by opening an issue in docker/for-mac

how about this one? docker/for-mac#6998 . nextjs (npm build) with Rosetta on causes 1 cpu 100% and hang, and with rosetta unchecked it works but slow , macos 13.6.1 , tested with latest 3 docker for mac releases (4.24, 4.25.1 , 4.25.2)

@robert914
Copy link

robert914 commented Nov 22, 2023

Not sure if it's related, but this issue also highlights an issue with running 64-bit images on M1 Macs in Rosetta 2: docker/for-mac#6796

Basically, if you run this command to show the CPU information:

docker run -it --rm --platform=linux/amd64 registry.access.redhat.com/ubi8/ubi:latest lscpu

If you run this on an Intel Mac, Windows or Linux machine, you'll see:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit

Which is what I would expect to see, both 32-bit and 64-bit op-mode support.

However, if you run this on an M1/M2 Mac with Rosetta enabled, you'll see:

Architecture:        x86_64
CPU op-mode(s):      32-bit

It's missing the 64-bit op-mode support. Why?

I'm wondering if all these various M1/M2 Rosetta 2 issues are stemming from the above missing 64-bit CPU op-mode support? I have some 64-bit images that will work fine on my M1 Mac, but then others will fail with strange segfaults or other kernel / disk access issues, but they all work fine on Intel machines.

@djcristi
Copy link

djcristi commented Nov 22, 2023

interesting , i've got this on, m1 , macos 13.6.1 , docker 4.25.2
Architecture: x86_64
CPU op-mode(s): 32-bit

@the-code-samurai-97
Copy link

the-code-samurai-97 commented Dec 23, 2023

I got the same error with M3 Max 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:05 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6031 arm64 and Docker version 24.0.7, build afdd53b
I was trying to create a Docker with Ubuntu 22.04 LTS and install bazel

@spkane
Copy link

spkane commented Jan 19, 2024

The switch to requiring users to use Rosetta instead of QEMU appears to have broken things pretty significantly, and there does not appear to be an obvious way to revert to the old QEMU-based behavior in Docker Desktop for Mac.

It is really easy to reproduce the core issue here with a test comment like this:

$ docker run --rm --platform linux/amd64 --name mongo bitnami/mongodb:6.0

Unable to find image 'bitnami/mongodb:6.0' locally
6.0: Pulling from bitnami/mongodb
e1386674fd12: Pull complete
Digest: sha256:fa089cf67d876b2be0f3903819f6579b45b090575ae48dc42a33fd0936412231
Status: Downloaded newer image for bitnami/mongodb:6.0

mongodb 20:36:18.66 INFO  ==>
mongodb 20:36:18.68 INFO  ==> Welcome to the Bitnami mongodb container
mongodb 20:36:18.70 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
mongodb 20:36:18.72 INFO  ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
mongodb 20:36:18.73 INFO  ==>
mongodb 20:36:18.75 INFO  ==> ** Starting MongoDB setup **
mongodb 20:36:18.82 INFO  ==> Validating settings in MONGODB_* env vars...
mongodb 20:36:18.98 INFO  ==> Initializing MongoDB...
mongodb 20:36:19.18 INFO  ==> Deploying MongoDB from scratch...
/opt/bitnami/scripts/libos.sh: line 346:   196 Illegal instruction     "$@" > /dev/null 2>&1

Note the Illegal instruction error message at the end. You get this when you run almost any binary inside the container.

  • Are there plans to allow people to revert to the old behavior until there is a fix that allows Rosetta to handle x86_64 properly?

Also, for the record, the lscpu output:

❯ docker run --rm --platform linux/amd64 --entrypoint lscpu --name mongo bitnami/mongodb:6.0
Architecture:                       x86_64
CPU op-mode(s):                     32-bit
Byte Order:                         Little Endian
CPU(s):                             8
On-line CPU(s) list:                0-7
Thread(s) per core:                 1
Core(s) per socket:                 8
Socket(s):                          1
Vendor ID:                          0x61
Model:                              0
Stepping:                           0x0
BogoMIPS:                           48.00
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass:    Vulnerable
Vulnerability Spectre v1:           Mitigation; __user pointer sanitization
Vulnerability Spectre v2:           Not affected
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected
Flags:                              fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm ssbs sb paca pacg dcpodp flagm2 front

@djs55
Copy link

djs55 commented Jan 24, 2024

@spkane thanks for the repro steps, we suspect Rosetta doesn't handle AVX instructions properly.

In the meantime could you try disabling Rosetta from the UI "Settings > General > Use Rosetta for x86/amd64 emulation on Apple Silicon". It should switch back to qemu after an "Apply & restart":
Screenshot 2567-01-24 at 9 51 33 am

Note you may have to scroll down to see the option.

@dzuelke
Copy link

dzuelke commented Jan 24, 2024

@spkane thanks for the repro steps, we suspect Rosetta doesn't handle AVX instructions properly.

No suspecting necessary ;)

From About the Rosetta Translation Environment | Apple Developer Documentation:

Rosetta translates all x86_64 instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions. If you include these newer instructions in your code, execute them only after verifying that they are available. For example, to determine if AVX512 vector instructions are available, use the sysctlbyname function to check the hw.optional.avx512f attribute.

@agrawroh
Copy link

@spkane thanks for the repro steps, we suspect Rosetta doesn't handle AVX instructions properly.

In the meantime could you try disabling Rosetta from the UI "Settings > General > Use Rosetta for x86/amd64 emulation on Apple Silicon". It should switch back to qemu after an "Apply & restart": Screenshot 2567-01-24 at 9 51 33 am

Note you may have to scroll down to see the option.

Yeah, that's what I ended up doing on my end to fix the error I saw here:
#384 (comment)

@padrepitufo
Copy link

I was a bit surprised to find this thread (I really should have looked here first 🤦‍♂️ ) - regardless I had been dealing with it on this ticket GoogleCloudPlatform/cloud-sdk-docker#356. The fix for me turned out to be either:

  • what is mentioned here (disable Use Rosetta for x86..)
    or
  • run softwareupdate --install-rosetta --agree-to-license and then re-enable Use Rosetaa for x86..

works on my machine 🤷‍♂️

@spkane
Copy link

spkane commented Jan 26, 2024

The lack of AVX support in Rosseta 2 is something that is unlikely to change and the workarounds that Docker is providing appear to work around this well enough.

Either disabling Rosetta or using -e EXPERIMENTAL_DOCKER_DESKTOP_FORCE_QEMU=1 for containers that need AVX, etc.

@erharb
Copy link

erharb commented Jan 29, 2024

I was a bit surprised to find this thread (I really should have looked here first 🤦‍♂️ ) - regardless I had been dealing with it on this ticket GoogleCloudPlatform/cloud-sdk-docker#356. The fix for me turned out to be either:

* what is mentioned here (disable `Use Rosetta for x86..`)
  or

* run `softwareupdate --install-rosetta --agree-to-license` and then re-enable `Use Rosetaa for x86..`

works on my machine 🤷‍♂️

Unfortunately the softwareupdate method is not working for me, disabling Rosetta is the only guaranteed solution at the moment for the specific containers that reproduce the problem consistently.

The slightly annoying thing is that it keeps re-enabling itself after each time a software update is taken.

@tomholford
Copy link

I had an issue with Rosetta + Docker pegging the CPU on Apple Silicon. For anyone encountering this issue with Vite, I found that installing @rollup/rollup-linux-arm64-gnu and setting platform: linux/arm64 in the docker-compose.yml helped resolve this issue.

@ps-hdavoodi
Copy link

@spkane thanks for the repro steps, we suspect Rosetta doesn't handle AVX instructions properly.

In the meantime could you try disabling Rosetta from the UI "Settings > General > Use Rosetta for x86/amd64 emulation on Apple Silicon". It should switch back to qemu after an "Apply & restart": Screenshot 2567-01-24 at 9 51 33 am

Note you may have to scroll down to see the option.

Thank you!

--platform linux/amd64 and this fixed my issue.

@mathisrome
Copy link

mathisrome commented Mar 17, 2024

Hi guys,

I'm trying to make an image to be able to launch dedicated servers (Satisfactory in this case) via SteamCMD on a Mac M1 Pro.

For this I need a 64-bit Linux architecture.

However when I launch my image with the --platform linux/amd64 option I get the following error: ERROR! Failed to install app '1690800' (Requires 64bit operating system)
When I run the lscpu command, the output returns: CPU op-mode(s): 32-bit.

Unfortunately when trying the solutions proposed above, none of them work.

Here are the steps to reproduce the bug:
Launch a debian container with the command:
docker run --platform linux/amd64 -it debian /bin/bash

And run the following command sequence:

export CPU_MHZ=2000 && apt-get update && apt-get upgrade -y && apt-get install software-properties-common curl wget unzip vim nano procps util-linux -y && apt-add-repository -y non-free && dpkg --add-architecture i386 && apt-get update && apt-get upgrade -y && apt-get install lib32gcc-s1 -y && mkdir steam-servers && cd steam-servers && curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" | tar zxvf - && ./steamcmd.sh +force_install_dir ./SatisfactoryDedicatedServer +login anonymous +app_update 1690800 -beta public validate +quit

Please remember to change the CPU_MHZ variable at the start of the command

@maxiedaniels
Copy link

I’m experiencing insanely slow performance using —platform Linux/amd64, but I have to because one of the Python libraries I’m using doesn’t support arm I guess. I’m confused about why it’s so slow though - is Docker not using Rosetta 2 on Mac silicon for some reason? I know Rosetta 2 emulates fairly quickly with everything I’ve thrown at it so I don’t know why things run at snails pace on docker with —platform..

@liuyehcf
Copy link

liuyehcf commented May 9, 2024

I can debug inside the Linux/amd64 container with the following steps:

# this will hang
ROSETTA_DEBUGSERVER_PORT=1234 ./main &

# gdb
gdb
(gdb) set architecture i386:x86-64
(gdb) file main
(gdb) target remote localhost:1234
(gdb) continue

But how can I analyze the coredump if the program crashed? I failed to find any doc related to this, does anyone konw how?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docker_desktop Improvements or additions to Docker Desktop
Projects
Status: Beta
Development

No branches or pull requests