signal Segmentation fault on macOS M2

Hi I'm using Docker 4.25.2 on macOS Sonoma 14.1.2.

I created a simple docker-compose.yml file:

version: "3"

services:

  mysql:
    image: mysql/mysql-server:5.7
    platform: linux/amd64
    restart: always
    environment:
      - MYSQL_RANDOM_ROOT_PASSWORD=1
      - MYSQL_USER=username
      - MYSQL_PASSWORD=password
      - MYSQL_DATABASE=prestashop
    networks:
      - ps

  phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest
    platform: linux/amd64
    restart: always
    environment:
      PMA_HOST: mysql
      PMA_USER: username
      PMA_PASSWORD: password
    ports:
      - "10001:80"
    networks:
      - ps

  prestashop_latest:
    platform: linux/amd64
    image: prestashop/prestashop:latest
    depends_on:
      - mysql
    ports:
      - 80:80
    volumes:
      - .:/var/www/html/modules/my_module
    environment:
      - DB_SERVER=mysql
      - DB_PREFIX=ps_
      - PS_INSTALL_AUTO=1
      - DB_USER=username
      - DB_PASSWD=password
      - DB_NAME=prestashop
      - PS_FOLDER_ADMIN=PSAdmin
      - PS_DOMAIN=localhost
      - PS_LANGUAGE=it
      - PS_COUNTRY=it
      - PS_FOLDER_INSTALL=installed
    networks:
      - ps

networks:
  ps:
    driver: bridge

Then I run

docker compose up -d --build

Everything goes fine, until I visit localhost and get ERR_EMPTY_RESPONSE error.

If I look at the container logs I see the following message:

[core:notice] [pid 1] AH00052: child pid 20 exit signal Segmentation fault (11)

I found a workaround to run without issues:

In Docker go to Settings -> General, choose osxfs (Legacy) as file sharing implementation and uncheck the Use Virtualization Framework checkbox. Apply & restart. This will work without issues

The report names no repository file or test; start by reproducing the docker-compose.yml stack on macOS Sonoma with Docker 4.25.2 and the listed virtualization and file-sharing settings. Compare the failing and workaround configurations, then determine whether a repository change or a documented compatibility limitation is appropriate.