[spip-dev] Page blanche sur l'affichage de *certains* plugins en 2.1.10

Dev
1

Salut,

Sur un site, après actualisation du core en 2.1.10 et des plugins, un
comportement très mystérieux de SPIP que je ne sais pas du tout comment
résoudre ni interpréter.

Dans l'espace privé, dans la page ?exec=admin_plugin&voir=recents, la
*présence* de certains plugins (même pas activés) provoque une page
blanche.

Les plugins en question sont les suivants :
a2a, autorite, bisous, cfg, champs_extras2_interface, crayons, motus,
saisies, spip-bonux.

Certains plugins (exemple "bisous") ne sont même pas utilisés ni même
activés, juste le répertoire est là suite à des tests et je l'ai jamais
enlevé, et ça suffit à faire planter.

En revanche, la présence des plugins suivants, et même leur activation,
ne provoquent pas d'erreur :
agenda_2_0, bandeau, champs_extras2, coordonnees, css_imbriques,
date_inscription, devise, grappes_2_0, html5, jappix_mini, pays,
selecteur_generique, themes_interface_privee, thickbox2, tickets.

Second mystère: côté public, le site plante toujours sur un
<INCLURE{fond=...}{env}>, même quand aucun plugin "planteur" n'est là.
C'est-à-dire que les premiers caractères (genre "plop") du fichier
inclus ne sont même pas affichés.

Le même site (git clone) sur mon système local ne provoque pas
d'erreur du tout. Le site distant est un système FreeBSD, en local j'ai
une Debian Testing.

Le cache est vidé, bien sûr.

Si quelqu'un a une idée, je suis désemparé et désabusé.

2

29/05/11, davux:

Second mystère: côté public, le site plante toujours sur un
<INCLURE{fond=...}{env}>, même quand aucun plugin "planteur" n'est là.
C'est-à-dire que les premiers caractères (genre "plop") du fichier
inclus ne sont même pas affichés.

Je me suis laissé déstabiliser par le premier mystère. Celui-ci était
une bêtise de ma part (un plugin présent mais pas activé).

L'impossibilité de poser certains plugins demeure, elle.

3

Salut davux,

4

29/05/11, bruno:

error_reporting(E_ALL^E_NOTICE);
ini_set ("display_errors", "On");
define('SPIP_ERREUR_REPORT', E_ALL^E_NOTICE);
define('SPIP_ERREUR_REPORT_INCLUDE_PLUGINS', E_ALL^E_NOTICE);

Je ne l'avais pas fait, mais si je le fais ça produit la même chose:
page blanche direct.

5

/etc/apache2/error.log ?

6

29/05/11, davux:

Dans l'espace privé, dans la page ?exec=admin_plugin&voir=recents, la
*présence* de certains plugins (même pas activés) provoque une page
blanche.

En fait, il semblerait que certains fichiers PNG (déclarés dans la
balise "icon" de plugin.xml) fassent planter PHP.

Je regarderai lesquels pour comprendre un peu mieux ce qui se passe,
mais dans tous les cas ça ne semble pas être un problème lié à SPIP
mais plutôt à PHP, GD2, ou une des libs que GD2 utilise, sous FreeBSD.

7

31/05/11, davux:

29/05/11, davux:
> Dans l'espace privé, dans la page ?exec=admin_plugin&voir=recents,
> la *présence* de certains plugins (même pas activés) provoque une
> page blanche.

En fait, il semblerait que certains fichiers PNG (déclarés dans la
balise "icon" de plugin.xml) fassent planter PHP.

Je regarderai lesquels pour comprendre un peu mieux ce qui se passe,
mais dans tous les cas ça ne semble pas être un problème lié à SPIP
mais plutôt à PHP, GD2, ou une des libs que GD2 utilise, sous FreeBSD.

Suite et fin de l'histoire...

J'ai fini par me rendre compte que ce ne sont pas les fichiers PNG à
proprement parler qui faisaient planter PHP, mais la lib png du
système. Et rien à voir avec SPIP : par exemple un bête appel à
imagecreatefrompng() faisait planter le bouzin. Le fait que le serveur
ne renvoie même pas le moindre en-tête HTTP montrait que c'était
vraiment un crash du module PHP d'Apache, et pas juste une page vide.

Ce lien http://forums.freebsd.org/showthread.php?t=20393 décrit
exactement la même situation. L'explication est que la libpng a été
mise à jour sans que tous les éléments qui en dépendent (dont PHP) ne
soient recompilés pour utiliser la nouvelle version, ce qui causait une
erreur de segmentation. Il a donc suffi de faire un
"sudo portupgrade -rf png" (longue opération), et tout est rentré dans
l'ordre.

C'est un bug vraiment vache, parce que c'est une prise de tête
incroyable pour le debugger, notamment à cause des imbrications de
pipelines et autres mécanismes dans SPIP, qui rendent le traçage
laborieux. Notamment il est très dur de savoir à quel moment SPIP
plante, en grande partie du fait que tout soit bufferisé (ce qui est
bien à d'autres niveaux, ce n'est pas une critique).

8

En effet, la sémantique de SPIP est devenue d'une complexité ingérable du fait de la multiplication de mécanismes similaires sans aucune vue unificatrice.
A quand le grand ménage ?

Committo,Ergo:Sum

9

Gogogo !

JLuc