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:
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)
Yeah my dears M1 users. Fixed for me when I added the
platform: linux/amd64
option to my docker-compose.yml file.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 justarm64v8/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:
For discoverability; https://github.com/docker/for-mac/issues/5846#issuecomment-881244406
@tianon do you have contacts in the Debian community to nudge that ticket?