php: Segmentation Fault with curl call

Hello everyone. I’m here to talk about an issue that caused me a big headache for a day. Curl is not working good with my Mac air with some urls (not all): it goes in segmentation fault.

My pc: MacBook Air with M1 processor. Dockerimage:

FROM php:7.4.1-apache

USER root

WORKDIR /var/www/html

RUN apt-get update && apt-get install -y \
        libpng-dev \
        zlib1g-dev \
        libxml2-dev \
        libzip-dev \
        libonig-dev \
        zip \
        curl \
        unzip \
    && docker-php-ext-configure gd \
    && docker-php-ext-install -j$(nproc) gd \
    && docker-php-ext-install pdo_mysql \
    && docker-php-ext-install mysqli \
    && docker-php-ext-install zip \
    && docker-php-source delete \
    && curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \
    && chown -R www-data:www-data /var/www/html \
    && a2enmod rewrite \
    && pecl install grpc \ 
    && docker-php-ext-enable grpc

COPY .docker/vhost.conf /etc/apache2/sites-available/000-default.conf
COPY ../. .
COPY ./startup_script.sh /tmp

WORKDIR /var/www/html/public/template_html

RUN curl -O -L https://github.com/ggiorginogrifo/templateEB/archive/refs/heads/main.zip \
    && unzip main.zip \
    && cp templateEB-main/* -r . \
    && rm  *.zip templateEB-main -rf

RUN useradd -ms /bin/bash www-deploy \ 
&& usermod -aG www-data www-deploy

USER www-deploy
WORKDIR /var/www/html

RUN mkdir -p bootstrap \
    && mkdir -p bootstrap/cache \
    && chmod 775 bootstrap -R \
    && /usr/local/bin/composer i \
    && cp resources/fonts vendor/szymach/c-pchart/resources -r

USER root

ENTRYPOINT ["/tmp/startup_script.sh"]

I tried also to gdb curl call but nothing relevant comes in output.

If I try to call curl -i -X GET "https://graph.facebook.com/facebook/picture?redirect=false" I get segmentation fault. It goes instead in success if I call https://www.google.com

Curl -V output: Schermata 2021-06-29 alle 17 05 04

Also, this is the docker-compose.yml file content:


version: '3.7'
services: 
    db: 
        container_name: mysql_container
        platform: linux/x86_64
        image: mysql
        restart: always
        ports: 
            - 3306:3306
        environment:
            MYSQL_USER: "${DB_USERNAME}"
            MYSQL_PASSWORD: "${DB_PASSWORD}"
            MYSQL_DATABASE: "${DB_DATABASE}"
            MYSQL_ALLOW_EMPTY_PASSWORD: 1
            MYSQL_ROOT_PASSWORD: ""

        volumes:
            - ./db:/var/lib/mysql
        networks:
            - app-network
    app:
        container_name: laravel_container
        build:
            context: .
            dockerfile: .docker/Dockerfile
        ports:
            - 8000:8000
        depends_on:
            - db
        volumes:
            - ./:/var/www/html
        networks:
            - app-network
networks:
    app-network:
        driver: bridge

Could someone help me with this problem? Also: I’ve read on docker official site that older libssl could cause segmentation fault, in fact I’ve tried to create an ubuntu:21.10 based image and the same call works.

P.S. Sorry if my explanation maybe would be not so clear, ask me anything that could help you.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 2
  • Comments: 18 (5 by maintainers)

Most upvoted comments

Yeah my dears M1 users. Fixed for me when I added the platform: linux/amd64 option to my docker-compose.yml file.

version: "2.2"
services:
    app:
        platform: linux/amd64
...

Thanks so much @leriel

None that likely wouldn’t already be subscribed to that ticket if they have an inkling for how to fix it. 😅 (Posting a nudge to the ticket itself is probably your best bet.)

I can say for sure that this isn’t something specific to the php image, since I can reproduce with just arm64v8/debian:buster-slim using https://packages.debian.org/experimental/qemu-user-static on my Debian bullseye host.

I also can’t reproduce against arm64v8/debian:bullseye-slim, so I’d posit that the chances of fixing this in Buster are very low (would require finding the correct fix, patching the package, and getting the release team to sign off on it, which is all doable, but involves a fair amount of [paper]work, so isn’t likely something the maintainer will do “just because” especially with Bullseye’s release right around the corner 😬).

Also I can confirm, and I’m so sorry that I replied so late. With the bullseye tag now I can use my php image and make any requests without that tedious “Segmentation Fault” issue.

I want also to thanks all of you that have commented out to this issue and now finally I think that I can close this.

This problem was solved for my machine with Docker Desktop 3.6.0. However, I just upgraded to 4.2.0 and had the same issue again.

I was able to resolve it by doing a factory reset in the docker settings. This does not make much sense to me, so my issue was probably caused by something different, but maybe this could work in your case as well?

Thanks for providing the workaround! However, this does not work in cases where a library is using curl to fetch data. In that case, all I could do is downgrade docker or use a different php image that is based on a newer version of debian.

I know this has already been linked to the root cause, but this is also mentioned in the “Known Issues” section in the release notes for Docker Desktop 3.4.0:

On Apple Silicon in native arm64 containers, older versions of libssl in debian:buster, ubuntu:20.04 and centos:8 will segfault when connected to some TLS servers, for example curl https://dl.yarnpkg.com. The bug is fixed in newer versions of libssl in debian:bullseye, ubuntu:21.04 and fedora:35.

For discoverability; https://github.com/docker/for-mac/issues/5846#issuecomment-881244406

@thaJeztah this looks similar yes.

@florentbolo are you using a Debian Buster based image? If so, I believe you’ve run into an issue with libcrypto that @djs55 has reported upstream: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989604

There are a couple of workarounds that you can use:

  1. Use another image, e.g.: alpine based, older or newer Debian based
  2. Tell curl to use older ciphers: curl --tls-max 1.2 https://graph.instagram.com

For (2), you might also need to specify a cipher using --ciphers based on what the server supports

@tianon do you have contacts in the Debian community to nudge that ticket?