WSOD sous Drupal

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Submitted by gudaillier on

Bonjour support,

Est-ce que l'un d'entre vous a eu à gérer un WSOD (white screen of death) ? Après vérification de tous les fichiers au niveau syntaxe et nos tests pour faire revenir un affichage du front, il semblerait y avoir un conflit au niveau de la base de données.
Merci par avance de votre aide précieuse.

Forum : 
Support général
Version de Drupal : 
6.x
Tags : 
wsod white screen of death

Soumis par gudaillier le 4 Novembre, 2011 - 15:58

Ajout de modules oui, pas de traffic car en dev, retouche de thème oui mais vérifié à fond notamment au niveau des erreurs de syntaxe php après le ?>
Augmentation de la mémoire allouée sur php
Restauration de backup de BDD

Toujours le même symptôme : WSOD;

Ce que je n'ai pas encore fait c'est désactiver les modules 1 à 1 pour vérifier mais ça va me prendre un temps de fou (120 modules en tout)

Soumis par Crayulayon le 7 Novembre, 2011 - 10:25

Essayez peut-être d'activer l'affichage des erreurs php

Dans le settings.php :
ini_set(“display_errors”, 1) ;

Ou bien dans un htaccess à la racine du site : php_flag display_errors on

Ou d'augmenter la limite de mémoire dans le php.ini

Ou de vider la table de sessions et les différentes tables de cache de la base.

Soumis par gudaillier le 7 Novembre, 2011 - 12:37

Merci pour cette suggestion !

Ou bien dans un htaccess à la racine du site : php_flag display_errors on >> pas de message d'erreur au moment du WSOD :(

Ou d’augmenter la limite de mémoire dans le php.ini >> déjà fait, toujours le WSOD

Ou de vider la table de sessions et les différentes tables de cache de la base. >> déjà fait, toujours le WSOD

Soumis par gudaillier le 7 Novembre, 2011 - 17:58

J'ai remarqué que je faisais partir le WSOD en mettant à jour les données de la table 'system' par celles d'une même version mais sans WSOD. Lorsque je fais une manip en admin, le wsod revient et je fais une MAJ de la table 'system' pour faire revenir l'affichage.
J'ai comparé les tables 'system' avant et après WSOD pour voir d'où vient l'anomalie mais le problème est que je ne vois pas d'où vient l'anomalie...
Il semblerait y avoir conflit au niveau de la gestion de modules et thèmes...

Soumis par gudaillier le 8 Novembre, 2011 - 10:55

Non, malheureusement je ne vois rien de la sorte dans la console... Au moment du WSOD, j'ai juste un texte banal qui indique le nom d'une région du template, dans le code HTML un tag qui mentionne le module context dans le nom de la class et puis c'est tout.

ex : '<'a id="context-block-region-left" class="context-block-region"'>' Left sidebar '<'/a'>'

Est-ce que ce serait context qui serait propice à faire crasher le site ?

Soumis par gudaillier le 16 Novembre, 2011 - 12:15

En fait, je m'aperçois que j'ai surtout des WSOD en étant connecté en admin et en contributeur, jamais, aussi bien qu'en utilisateur anonyme.
J'arrive temporairement à dégager un WSOD en faisant un truncate de la table 'system' et en remplaçant les données d'une autre version de la table system n'ayant pas eu de WSOD avant son dump.

Qu'est ce qui peut expliquer cette différence entre un admin et un contributeur qui n'a pas de WSOD ? Au niveau des droits ? Ce qui expliquerait que le contributeur n'ait pas déclenché un script douteux qui fait un WSOD ?