Crash php sur ob_get_contents()
Bonsoir,
Sur un plugin WordPress dont je suis l'auteur (une création de sommaire de documents), non encore totalement finalisé, j'avais, depuis quelques semaines (avait fonctionné correctement), une défaillance sur certains contenus, un bug à voir.
Je viens de finaliser des test.
Pour une raison totalement inconnue pour l'instant ob_get_content()interrompt la procédure courante qui l'appelle , pas un crash général (j'ai créé une trace -commentaire html -"avant" la fonction : ok, celui "après" n'est pas exécuté : la fonction exécute comme un "return" dans la procédure appelante).
Try catch ne renvoie rien, on plante dans le try, il n'y a pas d'exception générée.
Je n'ai donc pas de piste.
Je ne vois pas comment le contenu peut avoir une influence sur la fonction.
Je ne vois pas quel contexte d'exécution peut avoir une influence.
Je n'ai pas d'outil permettant d'analyser le crash interne de la fonction.
Il n'y a pas de message d'erreur (exécuté en mode debug chez OVH).
Merci d'avance pour des pistes.
Cordialement
Trebly
____________________________________________________________________________________________________________
Detail de contexte :
Plugin WordPress, widget de ma conception (non encore publié, en développement de compléments et qui fonctionnait parfaitement depuis deux mois) il traite le buffer en cours de création quand le contenu principal a été généré, un callback partiel en quelque sorte.
Le plugin est appelé après la création de ce contenu principal dans lequel je peux effectuer les replace utiles avant de repasser la main.
La génération dynamique de listes d'articles nécessite un callback pour faire un sommaire et quelques traitement de données numériques repérables par des balises spécifiques etc...
Quand le même plugin est appelé pour faire un sommaire d'un article isolé (sans liste d'articles) tout se déroule parfaitement bien. C'est la lecture du buffer qui permet de déterminer le type de document pour décider du mode de génération de sommaire.
Le crash se produit lors de cette lecture pour un type de contenus particulier, j'y perds mon latin puisque la lecture n'a en principe rien à voir avoir le contenu.
Mystère jusqu'à présent, rien de visible, mais l'anomalie demeure : ob_get_contents() = return ...
Bonsoir,
J'ai avancé.
L'application complète a été portée sur une autre plateforme et là tout marche.
Le code a été passé aux crible de xDebug il n'y a pas (plus, il y avait deux alertes mineures) une seule erreur, mais ça ne change rien.
- Le code c'est au moins 200 000 lignes de code exécuté avant l'incident (presque en fin d'exécution).
- L'incident est que ob_get_content(); se comporte exactement comme un "return". Autrement dit : n'exécute rien et la procédure en cours s'arrête et repasse la main au niveau supérieur.
- Try catch ne signale pas d'échec, ni code erreur bien sur.
- Le code HTML final généré est propre et l'affichage a lieu avec, simplement, l'absence du code que devrait générer la procédure arrêtée (une fenêtre vide)
- Il n'y a pas d'erreur signalée : OVH mode "ovhconfig" : développement.
- WordPress est en mode debug et ne signale rien.
- Avec le même code exécuté et les mêmes données sur l'autre plateforme (dans un cas serveur unix OVH partagé, dans l'autre Windows XP - oui encore), xDebug ne signale aucune anomalie.
- Le problème est reproductible avec une vingtaine de requêtes d'affichage différentes qui pour les unes produisent le problème, les autres non.
- Les versions de php-mysql ont été croisées 5.4.6 sur le "serveur" Windows et 5.5.x et 5.4.x testés sur OVH sans différence.
- Sur ma plateforme le code fonctionne.
- Sur l'hébergement OVH le phénomène apparaît pour certaines requêtes. Ces requêtes sont a priori plus consommatrices de ressources : je vais ajouter les infos xDebug qui peuvent être produites sur le serveur de développement mais pas sur le serveur OVH, cela donnera une idée de la taille mémoire et des requêtes SQL utilisées.
Il y a, je pense, deux hypothèses :
- Une limitation liée aux paramètres php (php.ini) certainement plus cossues sur ma machine dédiée au développement. Cette limitation provoquerait la non exécution de la fonction (et la sortie de la procédure) sans émission de code erreur majeur (l'exécution saute la procédure mais se continue), le comportement d'un "return" : là, la question précise est : au niveau des internes php qu'est-ce qui peut empêcher la fonction de s'exécuter et avoir l'effet d'un "return" dans la procédure appelante sans qu'il y ait de code erreur.
- Des données altérées qui entraîneraient l'incident bien après leur manipulation (problème classique)
Voilà, bien peu de pistes :
- Un peu de mesures (mémoire utilisée ? quand ? proche des limites OVH ?)
- Trouver un phénomène analogue dont la cause aurait été trouvée (je pense que le problème n'a rien à voir avec l'instruction ob_get_contents() en elle-même, mais avec ses requêtes de ressources peut-être bien).
Merci d'avance si quelqu'un à une idée.
Cordialement
Trebly
Avancées : cause probable : Erreur de ftp (où)retours ligne invalides CRLF-> CRCRLF : cherche outils
Bonjour,
Je suis sur le problème depuis deux semaines sans discontinuer.
En sus du ob_get_contents() devenant un return j'avais un blocage clavier répétitif pour les mises à jour de "pages".
Aucune réponse de la communauté WordPress qui ait fait avancé la question puis plus rien, en général on met en cause mes constats puis quand je propose de mettre à disposition la video sur cloud personne ne télécharge ni ne répond plus.
La désactivation de tous les plugins débloque le problème. La réactivation en cours a été commencée par mon widget. Il fonctionne, l'incident ne se produit plus. Mais pour travailler complètement il a besoin d'un environnement encore incomplet.
Il y a un problème que je pense majeur :
Le processus d'installation de plugin WordPress utilisant le chargement depuis la machine utilisateur (Win vers Linux) altère les fichiers en doublant les retours ligne, après une installation et un rapatriement via Filezilla un CRLF d'origine devient CRCRLF, qui dans des circonstances spécifiques non totalement identifiées soit la cause qui conduit au crash de php ou aux anomalies de comportement constatées.
Il semblerait que l'upload (depuis .zip) copie les fichiers sans traitement de fin de ligne (donc les fichiers Linux comprennent alors des fins de ligne x0D0A, puis que l'import vers Windows convertisse ces chaînes en x0D0D0A au lieu de 0D0A0D0A, ce qui de toute manière est totalement case-gueule (en js des suites de ligne après des doubles retour lignes semblent pouvoir casser les instructions d'où des défaillances d'exécution).
Le processus d'installation de plugin Wordpress que je suis (il y a deux méthodes) est le suivant :
- Téléchargment du zip vers répertoire local windows
- Utilisation de la procédure d'installation par Upload : installation puis activation
- L'encodage est UTF-8 partout
Ensuite des backup globaux sont effectués avec filezilla.
Qu'observe-t-on ?
- Les fichiers php après décompression locale windows sont normaux
- La taille originale décompression en environnement Windows dans un exemple est 11065c. et 258lignes vues par un éditeur
- Le même fichier après upload depuis le .zip et décompression en environnement Linux fait la même taille, ce qui est anormal
- Après rapatriement via filezilla la taille du fichier passe à 11316c. soit un embonpoint de 251c.
- L'examen en Hexa montre que les x:0D0A sont devenus x0D0D0A
- Cela n'explique pas tout cependant, il doit y avoir un problème d'encodage (mais je n'ai pas d'outil de comparaison binaire avec affichage hexa)
Conséquences observées ni expliquées en détail ni complètement :
- Après modification mineure et bien localisée d'un ficher (édition locale windows et envoi filezilla), j'obtenais (sans outils de débug) un écran blanc : plantage php
- Sans modification de code, la suppression des doubles CR dans 0D0D0A->0D0A, restitue une exécution normale.
Je ne veux pas ici rentrer plus loin dans les détails, mais les test montrent que les éditeurs ne réagissent pas tous de la même manière (suivant paramétrages), parfois corrigent automatiquement sans que l'on ne leur demande, ni en le signalant, ce qui fait que l'on peut ne rien voir. En particulier si le développeur qui utilise un éditeur qui nettoie les fichiers, fait les mêmes manips, il n'aura pas d'erreur.
A noter que trois éditeurs testés (phpstrom, ultra-edit, pspad) et des grep windows donnent des résultats différents.
Les éditions de test et analyse : fichier par fichier en hexa on été faits avec l'hexa de pspad.
Pour faire avancer le problème et traiter ensuite 11000 fichiers, il me manque des outilset je fais appel à vous (outils dont je n'ai jamais eu besoin depuis de nombreuses années) :
- Recherche de chaînes formulées si possible en Hexa dans les fichiers d'un répertoire et donnant les les noms de fichiers et le nombre d'instances (certain existent sur la papier mais ne voient pas les CR ni LF...)
- Remplacement des chaînes en traitement binaire dans un répertoire pour une famille donnée (*.php, *.js)
- Comparaison Hexa de fichiers individuellement définis par paires
- Comparaison binaire de répertoires donnant des résultats par fichiers de même noms résultats et/ou affichage Hexa
- dump-téléchargement et/ou affichage en format texte Hexa de fichiers quelconques depuis le répertoire d'un serveur (je sais faire mais je n'ai pas le temps encore de développer) : une appli php propre permettant le contrôle du contenu des fichiers sur l'environnement Linux
Evidemment la fonction qui semble bien en cause est le traitement de chargement de plugin de Wordpress issus de .zip téléchargés préalablement vers l'environnement Windows. Les mises à jour automatiques et le chargement depuis l'interface ne posant pas le problème (noyau WordPress OK), pas plus que les fichiers générés par mes soins depuis l'environnement Windows.
Compte tenu des conséquences observées qui semblent bien résulter d'erreurs php non visibles générées par ces chaines ou leur extensions dues à des éditions (suppression et ajout de lignes) assainir le code nécessite de repérer et remplacer toutes les chaînes pouvant être douteuses.
Merci d'avance de votre aide,
Cordialement
Trebly
Solution partielle au problème de transfert CRLF->CRCRLF
Bonjour,
Le problème dans sa génération est bien connu, mais à mon avis il y a des risques importants et des choses à faire.
Il est rapporté en notes sur le site Filezilla :
Filezilla : Data_Type
Citation:
Note[edit]
FileZilla does not analyse files uploaded as ASCII in any way. So if you have mixed line endings, somewhat "unexpected" things can happen. The native line ending for Windows is CR+LF. As this is what the FTP server expects when transferring files in ASCII, FileZilla on Windows does not apply any line ending translation at all. Now, imagine there is a text file with mixed Windows (CR+LF) and Unix (LF) line endings. Uploading that file from a Windows-based system to a Unix-based system will result in all CR+LF translated to LF only. Downloading that file again will make the FTP server convert all LF to CR+LF while sending it to FileZilla. As a result, all LF effectively are converted to CR+LF.
Another example is a text file with mixed line endings. FileZilla on Windows uploads that file to an FTP server running on Windows - no line ending conversion is done at all. Some text editors transparently handle mixed line endings so in such a text editor, the text file looks fine. However, other programs do not handle these cases and the text file might not work as expected in programs running on the server consuming that text file because they are confused by the still embedded Unix-style line endings (LF).
In yet another example, a Windows (CR+LF) text file was uploaded to a Unix-based FTP server in binary. If that file is downloaded in ASCII, the FTP server translates LF to CR+LF so the CR+LF line endings will be converted to CR+CR+LF. FileZilla on Windows does expect the file to already use CR+LF line encoding (per FTP specification), so no more translation is done. Depending on the text editor used, lines might be separated by an additional empty line now.
Wordpress contient une erreur grave en traitant comme un fichier binaire comme les autres le "zip" de plugin et dans le dézip qui ne tient pas compte de la plateforme et recopie comme binaires les fichiers textes (php,js,css etc.), le problème génère l'erreur rapportée dans la note Filezilla puis en cascade des plantages sévères de php.
La question des outils a une réponse partielle :
- WinGrep (sourceforge) permet d'effectuer les fonctions de recherche et remplacement de chaînes définies par des expressions régulières) - n'apparait pas dans les recherches Google
- Il me manque toujours un outil de comparaison de fichiers binaires (affichage en Hexa) par lots : avoir le nombre de différences et pouvoir éditer à la suite
Un autre problème reste entier, c'est le crash php sans erreur détectée, avec comportement aléatoire qui est généré dans certains cas de fins de lignes hétérogènes multiples (combinaisons générées par les erreurs décrite dans la doc Filezilla et que j'avais re-rédigée à la suite de mon analyse).
Il semble évident qu'un utilitaire indépendant et/ou un fonction standardisée devrait être intégrée dans bon nombre d'outils :
- Détection de fin de ligne mixte : Alerte
- Correction contrôlée
Les outils concernés sont :(ils ont des comportement variables source d'une incapacité du développeur à découvrir le problème)
- Editeurs
- Filezilla et autres ftp suvant options de test
- php (erreur ou warning sur fichiers à fins de lignes hétérogènes)
Je laisse ouvert le sujet sur ces questions d'outils, le processus complet n'est pas "solide", l'erreur unique peut rester invisible et conduire à des anomalies graves très difficiles à repérer.
Pour ma part ce problème vient de me coûter un mois de travail.
Pourtant, malgré sa réalité, à mon avis incontestable, je n'ai pratiquement eu aucune réponse sur les forum.
Cordialement
Trebly
Compléments et suite sur pb CRLF->CRCRLF etc.
Bonsoir,
Pendant les test j'ai porté en miroir l'application sur ma plateforme Windows (easyphp à la base mais totalement reparamétré - variable - et habillé) pour comparaison, test élémentaires etc.
On arrive à provoquer le phénomène. Par contre comme j'ai XDebug et mes propres outils, j'ai pu trouver des anomalies le plus souvent non majeures et faire un code plus clean. Mais, bien évidemment, si on ne développe pas sur une plateforme d'exploitation des problèmes comme celui qui fait l'objet de ce sujet sont absolument impossibles à résoudre (solution, bypass etc.).
La suite est que tout de même, comme je garde intactes les versions qui provoquent des anomalies incompréhensibles (quand on pense que l'informatique est une science exacte on nie leur existence, l'informatique n'est plus exacte quand la combinatoire rend dans la pratique inaccessibles l'identification des chaînes causales), donc plus tard on peut parfois mieux localiser le problème et peut-être comprendre. Dans le cas, peut être arriver à savoir où (plusieurs endroit peut-être) l'incident se produit avec un ou des CRCRLF.
En principe php ne devrait pas être sensible à cette anomalie puisque dès la lecture les caractères CR LF les blancs qui ne sont pas dans des chaînes devraient être éliminés. La question est donc comment php peut-il cafouiller puisque le code source n'a pas de CRCRLF ni CRLF dans des chaînes. La est le mystère. Du coté php pour l'instant mes mail ont eu une fin de non recevoir.
Ceci étant Wordpress n'utilisant pas d'outil de génération de templates comme SMARTY, les "templates sont du HTML entrecoupé d'instructions php", et là ?
A noter qu'avec javascript le problème est différent CRCRLF peut provoquer n'importe quoi (un double CRLF vu par l'éditeur - att c'est peut-être un CRCRLF - casse une suite d'instruction - cas que j'ai rencontré il y a quelques années), sans provoquer obligatoirement de crash terminal l'instruction ou la procédure n'est pas exécutée -> altération du traitement et des données -> résultat aléatoire.
Je vas donc dès que possible (quand j'aurais quelques heures), dupliquer l'application qui est sur mon serveur et pratiquer par dichotomie dans le remplacement des chaines CRCRLF par des CRLF (windows). Maintenant que je sais
- que le rétablissement des terminaisons normales partout rétablit le bon fonctionnement et
- que la plupart des plugin ayant ce défaut fonctionnent correctement
sachant qu'il est aisé d'activer, désactiver les plugins par groupes en quelques manip, je pense que par recoupement il sera possible :
- de localiser l'endroit qui a des conséquences
- de rendre le phénomène réversible et reproductible
en agissant sur une partie du code localisable.
Evidemment cela n'a rien à voir avec les recommandations qu'ont pu me faire divers administrateurs ou modérateurs et experts : isoler le problème en déshabillant le code ou en partant d'un cas simple, toutes choses impossibles (1.000.000 de lignes de code, 250 000 lignes CRCRLF corrigées sur 1000 pièces de code) donc le constat semblait réveiller chez certains des comportements schizophréniques, la réalité ne rentrant plus dans leurs modèles il ne peuvent que la contester ou entrer en crise d'incohérence avérée.
J'attends d'avoir toutes les billes pour renvoyer à la lecture des sujets correspondants qui sont très édifiants.
J'aimerai bien les déstabiliser sérieusement, c'est dans l'intérêt général.
Cordialement
Trebly
Erreur de "fin de ligne" (de LF <-> CRLF) crash aléatoire confirmé de PHP
Bonjour et bonne année,
Je confirme l'existence du problème de codage mixtes sur des sources de plugins WordPress où j'ai eu un nouvel incident, détecté très rapidement évidemment :
Le problème de codage "mixte accidentel" soumis à php sous Linux génère des crash php aléatoires.
J'ai une nouvelle fois récupéré via Filezilla un fichier avec des fins de lignes mal codées tel que décrit précédemment.
Le fichier s'exécute dans l'environnement Linux, mais après récupération sous windows on va évidemment trouver des interlignes doubles mais auxquels correspondent "x0Dx0Dx0A" malgré le traitement de reconnaissance de phpstorm (qui s'interroge évidemment) toute modification du fichier génèrera des séquences alternées conservant des 0D0D avec des 0D0A. Dès lors cela conduira à des résultats aléatoires, le plus simple étant un plantage sec ligne1 du code, le plus tordu était cette sortie de procédure.
Le traitement avec les expressions régulières que fait très bien "grepWin64" permet de mettre de l'ordre (plusieurs passes parfois nécessaires).
Cordialement
Trebly
