par
trebly » 23 mai 2015, 03:51
Bonsoir,
Je reviens vers vous pour vous tenir au courant. Le problème n'est pas résolu.
Remarque:
En revanche ton exemple n'imprime pas ce que tu dis, il imprime ceci (le commentaire après ob_get_contents s'affiche aussi) :
Code : Tout sélectionner
<div><!-- avant ob_get_content par a() --><!-- avant ob_get_content par a() --><!-- début de b() --></div>
Je pense que tout le monde a compris qu'il y avait une erreur dans la mise en forme du message il fallait lire "après" dans le code que j'avais un tout petit peu mis en forme avec un copier coller alors que le code comprend des notes.
Ceci étant, après installation sur le serveur dans un premier temps j'ai obtenu sur les mêmes données sur le serveur OVH l'erreur et sur mon serveur un fonctionnement correct. Mais après quelque chose d'inconnu il se sont mis à avoir un comportement identique avec le même défaut.
Les différences de config :
- Le serveur OVh fonctionne en mode "developpement" et WP est configuré en mode debug php 5.5.22 (mais le pb est identique avec 5.4 en changeant de moteur grâce ovhconfig), mémoire 512Mo
- Le serveur local de developpement est avec xDEBUG actif et le mode WP debug tourne en php 5.4.6, mémoire 375Mo
xDEBUG ne donne pas d'erreur.
J'ai complété le test avant exécution avec les fonctions ob_get_level() et ob_status(true) (trace avec commentaire ou var_dump) qui rapportent la même chose dans tous les cas et aucune anomalie.
Je teste et trace aussi les variables amont (paramètres passés et d'environnement), il n'y a rien.
La taille mémoire utilisée sur OVH est de 27Mo et de 57 sur le serveur de développement, donc RAS.
Quand ob_get_contents() fonctionne le besoin mémoire supplémentaire est de 2Mo donc RAS.
Il y a 4 niveaux de buffer, le dernier, celui des données HTML principales qui est celui que j'analyse et que je récupère et modifie quand ça marche, contient de manière variable environ de 60 à 100Ko (ce n'est que du texte, les images et d'autres éléments sont en href chargées par les requêtes générées par le navigateur après le premier chargement par les href ou ajax).
Donc rien à creuser.
Demain je teste avec ob_get_clean() et si ça fonctionne il n'y aura qu'à réécrire le contenu, c'est le seul contournement possible et auquel je viens de penser. Dans l'exécution normale c'est après avoir traité correctement la copie du buffer récupérée par bo_get_contents() que je fais un clean avant d'écrire le contenu modifié.
La différence entre les cas de bon fonctionnement et celui du défaut d'exécution est la nature des traitements.
En effet, dans le cas du fonctionnement correct on affiche un article unique.
Dans le cas du plantage il y a une boucle qui génère une liste d'articles, mais ce travail est terminé quand l'incident se produit et le code html généré fait apparaître les DIV successives sans anomalies. par contre c'est bien là la différence déterminante.
Donc c'est toujours le seule piste valide.
@rthur me conseille de faire un code simple, c'est vrai, c'est souvent la solution quand certains traitement posent problème. C'est ce que je fais très fréquemment et que j'ai fait là pour mettre au point le traitement du buffer (qui suit quand il est exécuté) avec des expressions régulières un peu complexes que j'ai fait tourner en simulation sur des jeux test les plus tordus possible.
Mais là, quand l'incident se produit c'est sur une fonction qui, réduite, n'a qu'une seule instruction et la pile d'appel est identique entre le cas du défaut et celui du bon fonctionnement. On en est au même stade d'exécution. Je ne vois vraiment pas comment isoler la procédure et recréer un environnement (buffers, utilisation mémoire etc...) identique, mais variable, extensible, avec l'espoir qu'en reconstruisant WP progressivement autour on verra apparaître le problème, dans dix ans... peut-être.
Reproduire un incident de ce type à partir de zéro, en complexifiant autour d'une seule instruction est à mon avis impossible et les chances de produire l'effet sont nulles. Seule une explication rationnelle du comportement observé pourrait permettre de connaitre la nature du problème.
Par contre, comme je l'ai rappelé plus haut, il y a sans aucun doute quelque chose qui se passe mal
sans erreur signalée lorsque la boucle de parcours de la liste est exécutée, ceci même si le résultat est correct, et ça je ne l'ai pas encore vu. Faire un trace détaillée et l'analyser pour espérer voir quelque chose est aussi une piste ?
Je peux aussi déshabiller les fonctions qui interviennent dans la boucle effectuée pour produire la liste d'articles, c'est peut-être bien la meilleure piste. Et ensuite produire et analyser un trace d'exécution concernant uniquement cette partie. Si le problème a disparu en ré-habillant les quelques centaines de ligne de code concerné, le phénomène peut peut-être réapparaître.
Une autre piste est d'avoir un cas similaire que personne malheureusement n'a jamais vu pour comparer et trouver les points communs, réduire la variété, on ne l'a pas.
Merci de votre aide, elle me force à réfléchir, en particulier en m'exprimant ici.
Cordialement
Trebly
Bonsoir,
Je reviens vers vous pour vous tenir au courant. Le problème n'est pas résolu.
Remarque:
[quote]En revanche ton exemple n'imprime pas ce que tu dis, il imprime ceci (le commentaire après ob_get_contents s'affiche aussi) :
[code]<div><!-- avant ob_get_content par a() --><!-- avant ob_get_content par a() --><!-- début de b() --></div>[/code][/quote]
Je pense que tout le monde a compris qu'il y avait une erreur dans la mise en forme du message il fallait lire "après" dans le code que j'avais un tout petit peu mis en forme avec un copier coller alors que le code comprend des notes.
Ceci étant, après installation sur le serveur dans un premier temps j'ai obtenu sur les mêmes données sur le serveur OVH l'erreur et sur mon serveur un fonctionnement correct. Mais après quelque chose d'inconnu il se sont mis à avoir un comportement identique avec le même défaut.
[b]Les différences de config :[/b]
[list][*]Le serveur OVh fonctionne en mode "developpement" et WP est configuré en mode debug php 5.5.22 (mais le pb est identique avec 5.4 en changeant de moteur grâce ovhconfig), mémoire 512Mo
[*]Le serveur local de developpement est avec xDEBUG actif et le mode WP debug tourne en php 5.4.6, mémoire 375Mo[/list]
xDEBUG ne donne pas d'erreur.
J'ai complété le test avant exécution avec les fonctions ob_get_level() et ob_status(true) (trace avec commentaire ou var_dump) qui rapportent la même chose dans tous les cas et aucune anomalie.
Je teste et trace aussi les variables amont (paramètres passés et d'environnement), il n'y a rien.
La taille mémoire utilisée sur OVH est de 27Mo et de 57 sur le serveur de développement, donc RAS.
Quand ob_get_contents() fonctionne le besoin mémoire supplémentaire est de 2Mo donc RAS.
Il y a 4 niveaux de buffer, le dernier, celui des données HTML principales qui est celui que j'analyse et que je récupère et modifie quand ça marche, contient de manière variable environ de 60 à 100Ko (ce n'est que du texte, les images et d'autres éléments sont en href chargées par les requêtes générées par le navigateur après le premier chargement par les href ou ajax).
Donc rien à creuser.
Demain je teste avec ob_get_clean() et si ça fonctionne il n'y aura qu'à réécrire le contenu, c'est le seul contournement possible et auquel je viens de penser. Dans l'exécution normale c'est après avoir traité correctement la copie du buffer récupérée par bo_get_contents() que je fais un clean avant d'écrire le contenu modifié.
La différence entre les cas de bon fonctionnement et celui du défaut d'exécution est la nature des traitements.
En effet, dans le cas du fonctionnement correct on affiche un article unique.
Dans le cas du plantage il y a une boucle qui génère une liste d'articles, mais ce travail est terminé quand l'incident se produit et le code html généré fait apparaître les DIV successives sans anomalies. par contre c'est bien là la différence déterminante.
Donc c'est toujours le seule piste valide.
@rthur me conseille de faire un code simple, c'est vrai, c'est souvent la solution quand certains traitement posent problème. C'est ce que je fais très fréquemment et que j'ai fait là pour mettre au point le traitement du buffer (qui suit quand il est exécuté) avec des expressions régulières un peu complexes que j'ai fait tourner en simulation sur des jeux test les plus tordus possible.
Mais là, quand l'incident se produit c'est sur une fonction qui, réduite, n'a qu'une seule instruction et la pile d'appel est identique entre le cas du défaut et celui du bon fonctionnement. On en est au même stade d'exécution. Je ne vois vraiment pas comment isoler la procédure et recréer un environnement (buffers, utilisation mémoire etc...) identique, mais variable, extensible, avec l'espoir qu'en reconstruisant WP progressivement autour on verra apparaître le problème, dans dix ans... peut-être.
Reproduire un incident de ce type à partir de zéro, en complexifiant autour d'une seule instruction est à mon avis impossible et les chances de produire l'effet sont nulles. Seule une explication rationnelle du comportement observé pourrait permettre de connaitre la nature du problème.
Par contre, comme je l'ai rappelé plus haut, il y a sans aucun doute quelque chose qui se passe mal [b]sans erreur signalée[/b] lorsque la boucle de parcours de la liste est exécutée, ceci même si le résultat est correct, et ça je ne l'ai pas encore vu. Faire un trace détaillée et l'analyser pour espérer voir quelque chose est aussi une piste ?
Je peux aussi déshabiller les fonctions qui interviennent dans la boucle effectuée pour produire la liste d'articles, c'est peut-être bien la meilleure piste. Et ensuite produire et analyser un trace d'exécution concernant uniquement cette partie. Si le problème a disparu en ré-habillant les quelques centaines de ligne de code concerné, le phénomène peut peut-être réapparaître.
Une autre piste est d'avoir un cas similaire que personne malheureusement n'a jamais vu pour comparer et trouver les points communs, réduire la variété, on ne l'a pas.
Merci de votre aide, elle me force à réfléchir, en particulier en m'exprimant ici.
Cordialement
Trebly
