Segmentation fault on x86_64 with MacOS Virtualization Framework enabled

[antoniofrignani]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID: 42EDF249-C0A8-4A3B-A709-4B2ADD41E5EF/20230505143852

Expected behavior

After a fresh local install of a Laravel project + Breeze (Vue), trying to build for production (sail npm run build) or starting a local hmr server (sail npm run dev) should work properly (using Docker for Mac on Intel Chip, v4.19.0)

Actual behavior

Both commands thows a Segmentation Fault error without further info.

  VITE v4.3.3  ready in 727 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: http://172.240.7.5:5173/
  ➜  press h to show help

  LARAVEL v10.9.0  plugin v0.7.4

  ➜  APP_URL: http://mysite.test
Segmentation fault

Information

Switching back to Docker for Mac v4.18.0 works as expected.

Possible workaround: disable Virtualization framework on v4.19+

Steps to reproduce the behavior

1. Create a fresh Laravel project (curl -s "https://laravel.build/example-app" | bash)
2. Install Laravel Breeze package (https://laravel.com/docs/10.x/starter-kits#laravel-breeze-installation) with the Vue stack
3. Run sail npm run dev should throw the Segmentation Fault error

[MihaelaStoica]

@antoniofrignani, would it be possible to submit a diagnostic report and then add the Diagnostics ID here?

[antoniofrignani]

@MihaelaStoica i've just updated my comment with a diagnostic ID

[irobin591]

I also have this issue.

There is no need to create a full Laravel project though. Installing Vite is enough to reproduce this issue:

• Create a new Vite project via docker run -it --rm -v "$PWD":/usr/src/app -w /usr/src/app node npm create vite@latest
• Change directory into the new Vite project: cd vite-project
• Install the Vite package via npm: docker run -it --rm -v "$PWD":/usr/src/app -w /usr/src/app node npm install
• Build for production or start a local hmr server: docker run -it --rm -v "$PWD":/usr/src/app -w /usr/src/app node npm run dev / docker run -it --rm -v "$PWD":/usr/src/app -w /usr/src/app node npm run build

Downgrading to 4.18.0 via https://docs.docker.com/desktop/release-notes/#4180 without changing the version of Vite is also a working workaround for me.

I also have access to a MacBook of a different model where this issue does not occur, so this might be hard to reproduce.

Specs of the MacBook that has the issue:

13" MacBook Pro 2020
CPU: 2,3GHz Quad-Core Intel Core i7
RAM: 16 GB 3733 MHz LPDDR4X 
OS: Ventura 13.3.1 (a)

Specs of the MacBook without the issue:

15" MacBook Pro 2017
CPU: 2,9GHz Quad-Core Intel Core i7
RAM: 16 GB 2133 MHz LPDDR3
OS: Ventura 13.3.1 (a)

[tisba]

I reported this issue to the yarn project (in hindsight not sure if I should have filed it here or at the node project instead). This issue here looks very similar to what I reported at yarnpkg/berry#5420. The issue at the yarn repository contains a minimal case to reproduce.

For me, this issue happens 100% of the time, for coworkers (almost identical hardware) it does not fail at all.

[antoniofrignani]

@irobin591 yes the issue is not direcly related to the framework itself, thanks for reproducing it with bare minimum boilerplate.

I'll watch the issue on the node/yarn side too since this seems strictly related, thanks @tisba for reporting it here.

[tisba]

I can confirm that downgrading to Docker Desktop 4.18.0 (104112) fixes the issue for yarn install seg fauting (see comment above). Thanks for the hint @irobin591 - I can at least build assets again :)

Update I only see the issue on x86. On arm64 (macOS 13.3.1 (a) (22E772610a)) Docker Desktop 4.19.0 works fine, without segmentation fault. So it looks like 4.19.0 broke something specifically on Intel.

I use this to test:

#!/bin/sh

# run via
#
#   docker run -it --rm -v "$(pwd)/test.sh":/app/test.sh:ro -w /app node:18.16 /app/test.sh

set -e

cat << EOF > ./package.json
{
    "packageManager": "yarn@3.5.1",
    "dependencies": {
        "@rails/ujs": "7.0.4"
    }
}
EOF

corepack enable

npm install -g npm@9.6.5

printf "uname -a: %s\n" "$(uname -a)"
printf "Node version: %s\n" "$(node --version)"
printf "Yarn version: %s\n" "$(yarn --version)"
printf "npm version: %s\n" "$(npm --version)"
printf "\n\n"

printf "Running: yarn install\n"

yarn install

[tisba]

@sam-thibault @MihaelaStoica: Can we provide something else to help with acknowledging/analysing the issue? (looking at the status/0-more-info-needed label)

[julienallexandre]

I have the same problem on a Laravel project with sail when I do the command sail npm run dev I get :

dev
vite

Segmentation fault

Docker version 23.0.5, build bc4487a
Docker Compose version v2.17.3
Node v18.16.0
NPM 9.6.7

[tisba]

In case you missed it, @julienallexandre, downgrading Docker Desktop one version seems to help until the issue is identified and fixed.

[julienallexandre]

@tisba thanks yes that's what I did :)

[doyeka]

Ran into the same issue today. I was using:
Node v19
Yarn 3.5.0
2.3 GHz Quad-Core Intel Core i7
Docker 4.19.0 & 4.20.1

I continually ran into silently failing yarn installs. Eventually, I tried a yarn install in the Docker terminal itself and received a seg fault.

Shoutout to you @tisba - I was losing my mind all afternoon.

Please fix this issue. @docker-robot

[tisba]

I can confirm that with Docker Desktop 4.20.1 (110738) the problem persists under x86 (macOS 13.3.1 (a) (22E772610a)).

None of my Apple Silicon devices show this problem, also tested with latest Docker Desktop 4.20.1. Update I also can't get it to crash on Apple Silicon using Rosetta x86 emulation.

[sergioharo]

I have same problem on i9 intel iMac. I can reproduce on latest docker desktop. Downgrading to 4.18 fixes issue but has networking problems of its own on Ventura 13.4.

Interestingly, I can reproduce with node v18 and 20 buster/bullseye images. However node v16 works fine.

[tisba]

Updated to macOS 13.4 (22F66) and the problem still persists.

[charlon]

As an added piece of information... I have 2 development setups I am currently working in and experiencing this same issue. I am using the bullseye images for my containers.

• Home: i9 Intel iMac, node versions v14, v16, v17 can build successfully, v18-20 results in seg fault
• Work: i5 Intel iMac, node versions v14-20 can all build successfully

Both machines are running: macOS 13.4 / Docker Desktop v4.20.1 / Node v18.16.0

[antoniofrignani]

Same problem with version 4.20.1, reverting to v 4.18 is the only working workaround afaik

[taro-ishihara]

I had same issue.

MacBook Pro (13-inch, 2020, Four Thunderbolt 3 ports)
Monterey 12.6.2 Intel Core i7

But it's fixed after downgraded to 4.18.0 without any changes of dockerfile, thank you.

[RogierW]

I had the same issue, but I use Laravel Mix instead of Vite. Downgrading Docker desktop to 4.18.0 did also the trick for me.

[tisba]

Still preproducable with 4.21.0 (113844) on Ventura 13.4.1 (22F82). Do the issue labels need to be updated to reflect that the bug is still present, @sam-thibault?

[Tynael]

Managed to reproduce the issue on macOS Ventura 13.4.1 (22F82) with Docker Desktop 4.20.1 (110738) and Docker version 24.0.2, build cb74dfc

[antoniofrignani]

Problem still relevant with latest 4.21.1 version

[shaoyie]

Confirmed this issue exists on macOS 13.6.4, Intel Core i5, Docker v4.28.

Upgrade to v4.28 to support the "include" tag in Dockerfile in a new project, then noticed the previous project broken...cost one whole day to find out the reason and solution...then come here...have to revert to v4.18 to save my other projects.

Seems the issue lay here more than half a year, so no plan to check this issue at all?

[testacode]

I tried to switch from VirtioFS to either gRPC FUSE or osxfs (Legacy) to disable the Use Virtualization framework, but neither worked because Docker was constantly crashing and wanted to reset.

macOS Sonoma v14.4 & Docker Desktop v4.28 (Engine: 25.0.3)

Same here, shit's unusable

[ralf57]

The issue is still present on macOS Sonoma v14.4.1 & Docker Desktop 4.29.0.
Disabling the Virtualization framework is not an option for me since performances decrease down to make it unusable.

[antoniofrignani]

I've switched to OrbStack since the issue popped up and solved the problem

Edit: I've just realized it's been one year since I opened the issue and no one GAF about that, so anybody who will stumble upon this lately: do yourelf a favor and switch tool, this is not going to be fixed anytime soon.

[ralf57]

I can only vouch for @antoniofrignani's suggestion to switch to OrbStack.
Amongst the Docker Desktop alternatives the I've tried (Podman, etc), OrbStack is the only one that worked flawlessly out of the box.
Furthermore, although not officially supported, it also works well with https://lando.dev/.

[schwemmer]

I've also switched to OrbStack and have no regrets. Even on my Apple Silicon Macs that don't experience this issue with Docker Desktop, I have switched to OrbStack and it's just faster than Docker Desktop.

[pablo-psi]

I've switched to OrbStack since the issue popped up and solved the problem

Edit: I've just realized it's been one year since I opened the issue and no one GAF about that, so anybody who will stumble upon this lately: do yourelf a favor and switch tool, this is not going to be fixed anytime soon.

Cheers @antoniofrignani, I didn't know about it! Seriously considering the switch now 🙌

[panosru]

I just switched! I previously switched to Rancher Desktop but eventually, I found Rancher lacking some features I liked in DD, so now I tried OrbStack and it seems to have all I need. Thanks!

[dgageot]

Hello everyone, so sorry for breaking your workflow! I'm currently trying to reproduce your issue, although there might be more than one.
In the meantime, if anyone of you is able to reproduce with a simple Dockerfile or a GitHub project that I cal build, that will help understand the root cause faster.

[eweidner]

@dgageot I found this to fail reliably on any system that showed the failure...

docker run -it node:18-slim bash;
npm install -g @angular/cli;
ng version;

[dgageot]

@dgageot I found this to fail reliably on any system that showed the failure...

docker run -it node:18-slim bash;
npm install -g @angular/cli;
ng version;

Thanks a lot! I can't reproduce on Docker Desktop 4.29, on an Intel MacPro.
Can you share which version of DD you use and which machine/OS you have?

[SheepReaper]

@dgageot I found this to fail reliably on any system that showed the failure...

docker run -it node:18-slim bash;
npm install -g @angular/cli;
ng version;

one liner: docker run -it -e NG_CLI_ANALYTICS=false node:18-slim npx --yes --package @angular/cli -- ng version

[dgageot]

Thanks @SheepReaper, that's handy! I've tried with this command too and same result: it works well. A colleague of mine has tried too and couldn't reproduce either.

Have you tried Docker Desktop 4.29? Can you share your version of macOS and type of Mac?

[sergioharo]

@dgageot I can reproduce on 4.29, iMac 2020 Intel i9 running Sonoma 14.4.1

You need to make sure you have Use Virtualization Framework enabled AND VirtioFS enabled.

Running the test command above gets me

docker run -it -e NG_CLI_ANALYTICS=false node:18-slim npx --yes --package @angular/cli -- ng version
Segmentation fault
npm notice
npm notice New minor version of npm available! 10.5.0 -> 10.6.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.6.0
npm notice Run npm install -g npm@10.6.0 to update!
npm notice

Using Virtualization Framework AND gRPC Fuse seems to work.

As does NO virtualization framework AND osxfs

Strangely after going back to VirtioFS, node:18-slim started working but node:19-slim still gets a segfault. Node 20+ seem to work.

[eweidner]

@dgageot I don't have a machine in a state to test this again right now, but as of May 2023, Nov 2023, and late Feb 2024 with all machines up to date on latest MacOS and Docker Desktop at that time I had 4 13" MBP (2020, Intel, i7 cpu) and 1 13" Macbook Air (2020, Intel, i7) all failed on this. I had 1 15" MBP (2018, Intel, i7) and 1 16" MBP (2019, Intel, i9) that did NOT have the problem with Mac Virtualization Framework on.

Turning off the Mac Virtualization Framework fixed all machines.

Also in my testing in November, node:16-slim did NOT have the problem. node:18-slim and node:20-slim DID have the problem. node:22-slim (not GA yet) did NOT have the problem.

Hope that helps.

[dgageot]

Keeping you posted: For now, we failed to reproduce on four different Intel Macs. Each time, we enabled Virtualization Framework enabled AND VirtioFS.
FWIW, I wonder howVirtioFS could have an impact, since both of the reproductions you shared don't use file sharing at all.

[dgageot]

OK, we've tried six Mac<=2018 and had no issue
But we found a 2020 MacBookPro with the issue!
I'll keep you posted

[antoniofrignani]

@dgageot thank for stepping in.

If that helps, you can have a look at the diagnostics i have uploaded when i first opened the issue.
Unfortunately I've switched to another tool the get the job done, so i can't help with the issue anymore.

[dgageot]

Here is an internal build which we think solves this issue. Could you give it a try?
https://desktop-stage.docker.com/mac/main/amd64/148395/Docker.dmg

[Amli]

A few days ago we upgraded our stack to nodejs 20 and suffered the same issue as described here (precisely a segfault when running webpack during image build with no mount) on a macbook pro 2020.

@dgageot I gave your internal build a try, switched back to use of the Virtualization Framework and used it yesterday for a few hours, everything works fine now 👏

I'll let others confirm that it works for them too.

Thanks for taking the time to reproduce and fix the issue !

[http-teapot]

I can confirm that it works on our end, too. Thank you for fixing this issue!

[dgageot]

FYI, the fix is planned for Docker Desktop v4.30.0

[pablo-psi]

FYI, the fix is planned for Docker Desktop v4.30.0

Great, thank you for fixing the issue! 🙏

[chaizeg]

Closing this issue because a fix has been released in Docker Desktop 4.30.0 . See the release notes for more details.

[ciekawy]

Interestingly I am facing yarn SIGSEGV on Docker Desktom 4.33... Do I need to check specific versions/settings? I have the VirtioFS enabled

UPDATE using simply NODE_OPTIONS="--max-old-space-size=4096" did help in my case