Segmentation Fault with curl call

[giorginogreg]

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:

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.

[wglambert]

I don't think there's anything we could change in the image to alleviate this, I'd try looking through or making an issue over at https://github.com/docker/for-mac/issues

[florentbolo]

Same issue for me.

On my docker containers,
curl https://graph.instagram.com
return : "segment fault" and curl google or whatelse returns the code.

But on my local terminal, curl instagram works...

I think this error appeared when I installed a VPN through Tunnelbclick. but maybe not.

Have you installed a vpn before?
Thanks

[tianon]

I'd suggest starting with a dedicated support forum, such as the Docker Community Forums, the Docker Community Slack, or Stack Overflow for further help debugging your environment / build.

[thaJeztah]

For discoverability; docker/for-mac#5846 (comment)

@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?

[tianon]

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 😬).

[florentbolo]

well said 😄
FYI, the same config with a mac non M1 works
Tanks again @thaJeztah for the quick fix

[fjahn]

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.

[leriel]

@giorginogreg i got the same issue, and funny enough, switching to respective amd64/php image solved the problem for me, this would be amd64/php:7.4.1-apache in your example.

That's one way to force use of amd64 image. Other would be to use buildx bake - this way you wouldn't have to change source image like above
docker buildx bake -f /path/to/compose.yml --set *.platform=linux/amd64 --set *.context=/path/to
(set context because buildx bake doesn't properly understand relative paths in compose)

[peuweb]

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

[w344701119]

Have you solved the problem? I have the same problem, my PHP version is 7.3, I have tried all your methods, but it still doesn't work

[fjahn]

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?

[w344701119]

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! Docker3.6 work well in my machine,I have re-installed the Docker

[thaJeztah]

@w344701119 @fjahn were you still seeing the issue with PHP images based on debian bullseye? (IIUC, the problem was when using the old "buster" base images in combination with QEMU user land emulation)

[fjahn]

No, the issue is fixed for me, but I assumed this was because of a newer version of Docker Desktop.

However, after upgrading to 4.2.0, I had similar symptoms that are described here. Since the issue was fixed with a Docker factory reset, I assume that it had nothing to do with this problem, I merely suggested this solution because I thought it might work for @w344701119 as well.

[thaJeztah]

Yes, be sure to have the php images in your image-cache up-to-date, so that it's using a version that uses debian:bullseye as base image.
The problem occurs if you try to use a php image based on the older debian:buster base image with QEMU emulation; Debian Buster has libraries that segfaults when trying to emulate x86 on arm (apple m1). That won't be fixed by debian (as buster reached EOL / mainstream support), so the fix is to either use native arm variants of the image (run without QEMU emulation), or to use a variant that's based on debian:bullseye.

[w344701119]

Thank you for your reply. I used a new machine (m1). Due to the project, I can only install php7.3. I installed Docker Desktop 4.2.0 and got a Segmentation Fault with curl . Later I reinstalled Docker Desktop 3.6. 0 is solved

[giorginogreg]

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.

[eduluz1976]

I just had the same problem, and it was solved when I updated the Dockerfile. Note that I'm using alpine as image base.

RUN apk add ca-certificates

Then it worked.

RUN curl -sS https://getcomposer.org/installer | php && mv composer.phar /usr/local/bin/composer