Apache et PHP : diagnostiquer une erreur Segmentation fault (11)

L’erreur Apache « child pid … exit signal Segmentation fault (11) » indique le plantage d’un processus natif. Elle provient souvent de PHP, d’une extension compilée ou d’une bibliothèque système. Voici comment identifier la cause sans augmenter aveuglément la mémoire.

Un serveur web qui renvoie ponctuellement une erreur 502, une page blanche ou une connexion interrompue peut masquer un plantage plus grave dans ses journaux. Une erreur 502 peut toutefois avoir plusieurs causes : par exemple, Nginx peut aussi signaler un en-tête trop volumineux envoyé par le serveur en amont.

Avec Apache et mod_php, le message ressemble souvent à ceci :

[core:notice] [pid 1234] AH00052: child pid 5678 exit signal Segmentation fault (11), possible coredumpLangage du code : CSS (css)

Avec PHP-FPM, Apache ou Nginx peut rester actif tandis qu’un processus PHP se termine :

php-fpm[1234]: [WARNING] [pool www] child 5678 exited on signal 11 (SIGSEGV - core dumped)Langage du code : CSS (css)

Dans les deux cas, le signal 11 correspond à SIGSEGV. Le processus a tenté d’accéder à une zone mémoire invalide et le noyau l’a arrêté.

Ce que signifie réellement Segmentation fault (11)

Une erreur de segmentation se produit dans du code natif. PHP est principalement écrit en C et charge de nombreuses extensions compilées. Apache, ses modules et les bibliothèques utilisées par ces composants contiennent eux aussi du code natif.

Les suspects habituels sont donc :

• une régression dans PHP ;
• une extension PHP défectueuse ou incompatible ;
• une extension chargée deux fois ;
• un module Apache ;
• une bibliothèque native utilisée par une extension ;
• une incompatibilité après une mise à jour partielle ;
• un cache d’opcodes ou un JIT révélant un bug ;
• un binaire ou un fichier partagé corrompu ;
• plus rarement, un problème matériel.

Un script PHP ordinaire ne devrait pas pouvoir provoquer directement un accès mémoire invalide. Il peut néanmoins déclencher un bug présent dans l’interpréteur ou dans une extension native.

Un segfault n’est pas une erreur de limite mémoire PHP

Il faut distinguer deux erreurs très différentes.

Dépassement de memory_limit

Lorsqu’un script dépasse la mémoire autorisée par PHP, celui-ci renvoie normalement une erreur explicite :

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted

Le processus PHP reste alors capable de détecter le dépassement et d’écrire son message d’erreur.

Erreur de segmentation

Avec un segfault, le processus s’interrompt brutalement après un accès mémoire invalide. Il peut disparaître avant que PHP puisse journaliser une erreur applicative exploitable.

Augmenter memory_limit peut modifier les conditions du crash, mais cela ne constitue ni un diagnostic ni une correction générale d’un SIGSEGV.

Ne passez donc pas immédiatement la limite à -1. Vous risqueriez seulement de masquer un problème, d’augmenter la consommation du serveur ou de déplacer le plantage.

Étape 1 : identifier le processus qui plante

Le message visible dans Apache ne prouve pas toujours qu’Apache lui-même contient le bug. Tout dépend de la manière dont PHP est exécuté. Cette distinction est détaillée dans le guide consacré au fonctionnement d’Apache avec PHP-FPM et MPM Worker.

Apache avec mod_php

Avec mod_php, PHP s’exécute à l’intérieur des processus enfants d’Apache. Une extension PHP qui plante emporte donc le processus Apache avec elle.

apache2ctl -M | grep -i php

Une ligne comme php_module indique généralement que PHP est chargé comme module Apache.

Apache avec PHP-FPM

Avec PHP-FPM, Apache transmet les scripts à un service séparé. Le journal Apache peut alors montrer une erreur de proxy ou une réponse interrompue, tandis que le véritable crash apparaît dans le journal PHP-FPM ou dans le journal système.

apache2ctl -M | grep -E 'proxy_fcgi|php'
systemctl list-units --type=service 'php*-fpm.service'Langage du code : PHP (php)

Sur un serveur utilisant PHP-FPM, adaptez les commandes à la version installée, par exemple php8.4-fpm ou php8.5-fpm.

Étape 2 : relever le contexte exact du crash

Avant de modifier la configuration, notez l’heure, le PID, la version de PHP, les mises à jour récentes et la requête concernée.

date
php -v
apache2ctl -v
apache2ctl -M
uname -a

Listez également les paquets PHP installés :

dpkg -l 'php*' | grep '^ii'Langage du code : JavaScript (javascript)

Sur Ubuntu ou Debian, consultez l’historique récent d’APT :

grep -E '^(Start-Date|Commandline|Upgrade|Install|Remove):' \
	/var/log/apt/history.logLangage du code : JavaScript (javascript)

Si les crashes ont commencé juste après une mise à jour, ce rapprochement fournit une première piste. Il ne prouve toutefois pas que le dernier paquet modifié est nécessairement coupable.

Étape 3 : consulter tous les journaux utiles

Ne vous limitez pas au fichier error.log du virtual host. Le crash peut être enregistré par Apache, PHP-FPM, systemd ou le noyau.

Journaux Apache

journalctl -u apache2 --since '-30 minutes'
tail -n 200 /var/log/apache2/error.logLangage du code : JavaScript (javascript)

Pour suivre les nouvelles entrées en direct :

journalctl -fu apache2

Journaux PHP-FPM

journalctl -u php8.4-fpm --since '-30 minutes'
journalctl -fu php8.4-fpmLangage du code : JavaScript (javascript)

Remplacez 8.4 par la version réellement utilisée par le site.

Messages du noyau

Le noyau peut enregistrer le binaire, l’adresse mémoire et la bibliothèque dans laquelle le processus s’est arrêté :

journalctl -k --since '-30 minutes' | grep -Ei 'segfault|trap|general protection'
dmesg -T | grep -Ei 'segfault|trap|general protection'Langage du code : JavaScript (javascript)

Une ligne mentionnant une bibliothèque ou une extension précise constitue un indice précieux. Elle ne remplace pas une backtrace, mais elle permet souvent de réduire la liste des suspects.

Étape 4 : corréler le plantage avec une requête HTTP

Le PID seul ne permet pas de connaître l’URL responsable. Comparez l’heure du crash avec les journaux d’accès du site.

grep '19/Jun/2026:16:42:' /var/log/apache2/access.log
grep '19/Jun/2026:16:42:' /var/log/apache2/example-access.logLangage du code : JavaScript (javascript)

Examinez les requêtes immédiatement antérieures au crash :

• une page WordPress précise ;
• une requête AJAX ;
• une tâche WP-Cron ;
• une génération d’image ;
• un import ou un export ;
• une commande REST API ;
• une opération WooCommerce ;
• un script CLI lancé par cron.

Si la même URL déclenche systématiquement le crash, vous disposez d’un cas reproductible. C’est nettement plus utile qu’un journal rempli de PID différents.

Étape 5 : vérifier si le problème est reproductible en CLI

Lorsqu’un traitement peut être exécuté sans serveur web, reproduisez-le avec PHP en ligne de commande. Vous éliminez ainsi Apache, FastCGI et la gestion des processus FPM de l’équation.

php -d display_errors=1 /chemin/vers/script.php

Pour WordPress, utilisez WP-CLI lorsque l’action possède une commande équivalente :

sudo -u www-data wp cron event run --due-now \
	--path=/home/www/example.com/public_htmlLangage du code : JavaScript (javascript)

Si PHP CLI plante lui aussi, Apache n’est probablement pas la cause principale. Orientez alors le diagnostic vers PHP, ses extensions, la bibliothèque appelée ou le code qui déclenche le bug.

Attention : les SAPIs CLI, Apache et FPM peuvent charger des fichiers php.ini différents.

php --ini
php -i | grep 'Loaded Configuration File'Langage du code : JavaScript (javascript)

Étape 6 : inventorier les extensions PHP chargées

Les extensions natives représentent l’une des causes les plus fréquentes de crash PHP. Commencez par obtenir leur liste.

php -m
php --ri opcache
php --ini

Recherchez également les déclarations extension et zend_extension :

grep -RniE '^[[:space:]]*(zend_)?extension[[:space:]]*=' \
	/etc/php/Langage du code : JavaScript (javascript)

Une extension peut être activée dans plusieurs fichiers ou pour plusieurs SAPIs. Vérifiez la configuration effectivement chargée par le processus concerné.

Tester PHP sans php.ini

L’option -n lance PHP sans charger son fichier de configuration principal ni les extensions configurées par celui-ci :

php -n /chemin/vers/script.php

Si le script plante avec la configuration normale, mais fonctionne avec php -n, une extension ou une directive de configuration devient fortement suspecte.

Ce test ne suffit pas toujours, car le script peut dépendre d’extensions indispensables. Il sert surtout à confirmer que la configuration chargée participe au problème.

Étape 7 : désactiver les extensions suspectes une par une

Ne désactivez pas toutes les extensions simultanément sur un serveur de production. Procédez méthodiquement, de préférence sur une préproduction capable de reproduire le crash.

Commencez par les composants récemment :

• installés ;
• mis à jour ;
• recompilés ;
• activés ;
• modifiés dans leur configuration.

Sur Debian ou Ubuntu, une extension peut être désactivée pour une SAPI précise avec phpdismod :

sudo phpdismod -v 8.4 -s fpm imagick
sudo systemctl restart php8.4-fpmLangage du code : CSS (css)

Pour mod_php :

sudo phpdismod -v 8.4 -s apache2 imagick
sudo systemctl restart apache2Langage du code : CSS (css)

Après chaque changement :

1. vérifiez la syntaxe de la configuration ;
2. redémarrez uniquement le service concerné ;
3. rejouez exactement la même requête ;
4. contrôlez les journaux ;
5. notez le résultat.

Réactivez ensuite l’extension avec :

sudo phpenmod -v 8.4 -s fpm imagick
sudo systemctl restart php8.4-fpmLangage du code : CSS (css)

Adaptez la version, la SAPI et le nom de l’extension à votre système.

Étape 8 : tester OPcache et le JIT séparément

OPcache est le cache d’opcodes intégré à PHP. Il ne faut pas le confondre avec APCu, qui stocke des données applicatives en mémoire partagée.

Pour un test ponctuel en CLI, désactivez OPcache :

php \
	-d opcache.enable_cli=0 \
	/chemin/vers/script.php

Si le JIT est activé, testez également sans JIT :

php \
	-d opcache.jit=0 \
	-d opcache.jit_buffer_size=0 \
	/chemin/vers/script.php

Sur un serveur web, modifiez temporairement la configuration de la SAPI concernée, puis redémarrez PHP-FPM ou Apache.

Ne laissez pas OPcache désactivé durablement en production uniquement parce que cela masque le crash. Cherchez ensuite la version précise de PHP ou de l’extension responsable.

Étape 9 : vérifier les paquets et bibliothèques

Une mise à jour partielle peut laisser PHP, une extension et sa bibliothèque native dans des versions incompatibles.

sudo apt update
apt list --upgradable
sudo apt --fix-broken install
sudo dpkg --auditLangage du code : PHP (php)

Identifiez le paquet qui fournit un fichier chargé :

dpkg -S /usr/lib/php/20240924/imagick.so

Vérifiez ses dépendances dynamiques :

ldd /usr/lib/php/20240924/imagick.so

Le numéro du répertoire d’API PHP varie selon la version installée. Utilisez le chemin retourné par votre système.

Si un fichier appartient à un paquet officiel suspecté d’être corrompu, sa réinstallation peut être pertinente :

sudo apt install --reinstall php8.4-imagickLangage du code : CSS (css)

Une réinstallation ne doit toutefois intervenir qu’après avoir identifié le bon paquet. Réinstaller toute la pile au hasard détruit des indices sans garantir la correction.

Étape 10 : examiner les coredumps avec coredumpctl

Sur un système utilisant systemd-coredump, coredumpctl permet de lister les processus ayant produit un core dump, d’afficher leurs métadonnées et de lancer un débogueur.

sudo coredumpctl list --since '-1 hour'Langage du code : PHP (php)

Filtrez selon le processus concerné :

sudo coredumpctl list apache2
sudo coredumpctl list php-fpm8.4
sudo coredumpctl list phpLangage du code : PHP (php)

Les noms exacts dépendent du binaire et de la distribution. La colonne EXE indique le chemin de l’exécutable ayant planté.

Affichez les informations du crash le plus récent :

sudo coredumpctl info -1

Vous y trouverez notamment :

• le PID ;
• l’utilisateur du processus ;
• le signal reçu ;
• l’exécutable ;
• la ligne de commande ;
• l’état du fichier core ;
• parfois une première pile d’appels.

Pour extraire le core dump :

sudo coredumpctl dump -1 \
	--output=/tmp/php-segfault.coreLangage du code : JavaScript (javascript)

Le fichier peut contenir des fragments de mémoire du processus : données de requêtes, secrets, contenus ou identifiants. Ne le publiez jamais sans contrôle.

Étape 11 : générer une backtrace avec GDB

Une backtrace indique la pile des fonctions actives au moment du crash. Elle permet souvent d’identifier une extension ou une bibliothèque précise.

Installez GDB :

sudo apt install gdb

Lancez directement GDB sur le dernier coredump enregistré :

sudo coredumpctl debug -1

Dans GDB, demandez une backtrace complète :

thread apply all bt full

Une version plus courte peut être obtenue avec :

bt

Quittez GDB avec :

quit

Sans symboles de débogage, la pile peut contenir de nombreux points d’interrogation. Installez les paquets de symboles correspondant exactement aux binaires et bibliothèques concernés lorsque votre distribution les fournit.

Reproduire un crash PHP CLI sous GDB

gdb --args php /chemin/vers/script.php

Dans GDB :

run
thread apply all bt full

Cette méthode est particulièrement pratique lorsqu’un script CLI reproduit systématiquement le crash.

Déboguer Apache en mode mono-processus

Si le crash ne se produit qu’avec Apache et mod_php, le mode -X exécute Apache dans un processus unique. Il facilite le suivi avec GDB.

Cette opération interrompt le fonctionnement normal du serveur. Réservez-la à une machine de test ou à une fenêtre de maintenance maîtrisée.

sudo systemctl stop apache2
sudo gdb --args /usr/sbin/apache2 -X

Dans GDB :

run

Rejouez ensuite la requête fautive depuis un autre terminal. Après le crash :

thread apply all bt full

Lorsque le diagnostic est terminé, quittez GDB puis redémarrez le service :

sudo systemctl start apache2

Selon la distribution, Apache peut exiger des variables d’environnement ou des arguments supplémentaires lorsqu’il est lancé directement. Le guide officiel d’Apache détaille cette méthode de débogage.

Tester avec Valgrind lorsque le crash est reproductible

Valgrind peut détecter des accès mémoire invalides. Il ralentit fortement l’exécution, mais il apporte parfois plus de détails qu’une simple backtrace.

sudo apt install valgrind

USE_ZEND_ALLOC=0 valgrind \
	--tool=memcheck \
	--track-origins=yes \
	--leak-check=full \
	php /chemin/vers/script.php

USE_ZEND_ALLOC=0 désactive l’allocateur mémoire propre à Zend pour permettre à Valgrind d’observer directement davantage d’opérations.

Valgrind produit beaucoup de bruit. Concentrez-vous sur la première erreur d’accès invalide et sur la bibliothèque ou l’extension mentionnée dans sa pile.

Cas particulier : WordPress déclenche le crash

Un plugin ou un thème WordPress écrit uniquement en PHP provoque rarement à lui seul un véritable segfault. Il peut cependant appeler une fonction qui révèle un bug dans une extension native.

Par exemple, une action WordPress peut solliciter :

• Imagick pour transformer une image ;
• libxml pour analyser un document ;
• cURL ou OpenSSL pour une connexion distante ;
• mbstring ou ICU pour manipuler du texte ;
• un loader propriétaire ;
• une extension de cache ;
• une bibliothèque de compression ou d’archivage.

Pour isoler le chemin applicatif, utilisez une préproduction et désactivez les extensions WordPress par groupes.

Lorsque l’intégrité d’une extension WordPress est suspecte, vous pouvez également la sauvegarder puis la réinstaller proprement. Le guide sur l’archivage et la réinstallation d’extensions avec WP-CLI détaille cette procédure.

wp plugin list --status=active
wp plugin deactivate --allLangage du code : PHP (php)

Réactivez ensuite les plugins progressivement :

wp plugin activate plugin-a plugin-b plugin-c

Si la désactivation d’un plugin supprime le crash, cela ne signifie pas forcément que son code PHP corrompt la mémoire. Le plugin peut simplement être le seul composant qui appelle l’extension native fautive.

Vérifier les tâches WP-Cron et les commandes planifiées

Lorsqu’un crash semble aléatoire, cherchez un traitement périodique : optimisation d’images, sauvegarde, génération de rapports, nettoyage de base ou synchronisation externe.

wp cron event list \
	--fields=hook,next_run_relative,recurrenceLangage du code : PHP (php)

Exécutez une tâche suspecte manuellement sur une préproduction :

wp cron event run nom_du_hook

Une tâche reproductible peut ensuite être lancée sous GDB ou Valgrind si elle possède un équivalent CLI.

Quand faut-il redémarrer Apache ou PHP-FPM ?

Un redémarrage remplace les processus ayant planté et recharge la configuration. Il ne corrige pas la cause.

Avant de redémarrer Apache, vérifiez sa configuration :

sudo apache2ctl configtest
sudo systemctl reload apache2

Utilisez reload lorsque seule la configuration Apache doit être relue et que le contexte le permet. Utilisez un redémarrage après une modification exigeant le remplacement complet des processus :

sudo systemctl restart apache2

Pour PHP-FPM :

sudo php-fpm8.4 -t
sudo systemctl reload php8.4-fpmLangage du code : CSS (css)

Selon la distribution, le binaire de test peut s’appeler php-fpm8.4, php-fpm ou utiliser un autre chemin.

Les fausses bonnes solutions

Augmenter systématiquement memory_limit

Cette modification traite les erreurs d’épuisement contrôlé de la mémoire PHP. Elle ne corrige pas, en règle générale, un accès mémoire invalide dans du code natif.

Redémarrer le serveur à chaque crash

Le redémarrage efface parfois les symptômes pendant quelques minutes. Il détruit aussi le contexte immédiat et ne fournit aucune explication.

Désinstaller plusieurs extensions à la fois

Si le problème disparaît, vous ignorez toujours laquelle était responsable. Utilisez une recherche dichotomique ou désactivez les composants par groupes cohérents.

Supprimer les journaux ou les coredumps trop tôt

Ils constituent souvent les seules traces exploitables. Copiez les informations nécessaires avant toute rotation, purge ou réinstallation.

Rétrograder au hasard

Une rétrogradation peut confirmer une régression, mais elle doit viser un paquet précis et rester compatible avec ses dépendances.

Procédure de diagnostic rapide

L’ancien cas APC et PHP 5.4

La première version de cet article décrivait un crash apparu après une mise à jour de php-apc sous PHP 5.4.

L’augmentation de memory_limit n’avait pas suffi. La désinstallation de l’extension APC avait fait disparaître les erreurs, ce qui désignait l’extension ou son interaction avec cette version de PHP comme cause probable.

Cette solution historique ne doit plus être reproduite telle quelle. APC a depuis été remplacé par deux composants distincts : OPcache pour le cache d’opcodes et APCu pour le cache de données. Consultez le guide consacré au remplacement d’APC par OPcache et APCu sur un serveur Linux.

• PHP 5.4 est obsolète ;
• le paquet php5-apc n’est plus utilisé ;
• OPcache assure désormais le cache d’opcodes ;
• APCu couvre le cache de données en mémoire partagée ;
• les chemins de configuration ont changé ;
• le diagnostic moderne doit partir des journaux et du coredump.

La leçon reste toutefois valable : lorsqu’un problème commence après la mise à jour d’une extension native et disparaît lorsqu’elle est désactivée, cette extension devient le premier composant à examiner.

Questions fréquentes

Que signifie le signal 11 sous Linux ?

Le signal 11 correspond généralement à SIGSEGV. Le noyau l’envoie lorsqu’un processus tente d’accéder à une zone mémoire invalide.

memory_limit peut-il provoquer un segfault PHP ?

Un dépassement normal de memory_limit produit une erreur PHP « Allowed memory size exhausted ». Un segfault indique plutôt un bug ou une incompatibilité dans du code natif, même si la consommation mémoire peut influencer les conditions qui le déclenchent.

Comment savoir si Apache ou PHP-FPM a planté ?

Vérifiez la SAPI utilisée et consultez les journaux des deux services. Avec mod_php, le crash apparaît dans un processus Apache. Avec PHP-FPM, le processus FPM se termine séparément.

Comment identifier l’extension PHP responsable ?

Comparez l’exécution normale avec php -n, puis désactivez les extensions suspectes progressivement. Une backtrace GDB peut confirmer l’extension ou la bibliothèque active au moment du crash.

Où trouver les coredumps sous Ubuntu ou Debian ?

Lorsque systemd-coredump les collecte, utilisez coredumpctl list, coredumpctl info et coredumpctl debug. Leur disponibilité dépend de la configuration et de la politique de conservation du système.

Un plugin WordPress peut-il faire planter PHP ?

Un plugin peut déclencher un chemin de code qui révèle un bug dans PHP ou une extension native. Sa désactivation peut donc supprimer le symptôme sans prouver que son code PHP est directement responsable de la corruption mémoire.

Faut-il redémarrer le serveur après un segfault ?

Apache et PHP-FPM remplacent souvent automatiquement un processus enfant mort. Un redémarrage peut être nécessaire après une modification de configuration, mais il ne corrige pas la cause du plantage.

Conclusion

Une erreur Segmentation fault (11) n’est pas une simple erreur PHP que l’on corrige en augmentant une valeur dans php.ini.

Elle signale le plantage d’un processus natif. Il faut donc identifier l’exécutable concerné, reproduire la requête, isoler les extensions et exploiter les informations fournies par le noyau et le coredump.

Dans les cas simples, la désactivation d’une extension récemment mise à jour suffit à confirmer le diagnostic. Dans les cas plus difficiles, une backtrace GDB transforme enfin le mystérieux « child pid exited » en piste technique exploitable.

Le redémarrage remet le service debout. Le diagnostic évite qu’il retombe.

Sources et ressources

• Apache HTTP Server : guide de débogage
• PHP : générer une backtrace avec GDB
• PHP : fichier de configuration
• PHP : documentation OPcache
• PHP : options de la ligne de commande
• Debian : manuel de coredumpctl
• GDB : documentation officielle
• Valgrind : manuel officiel

Report a typo