Plantage avec Xdebug à partir du tag 2.5.3 du plugin #5

Closed
opened 10 months ago by rastapopoulos · 11 comments

Cette fois-ci j'ai un truc reproductible ! :D

J'ai utilisé le squelette-thème Photographe qui est public là :
https://git.spip.net/spip-contrib-squelettes/photographe

Avec un PHP qui a Xdebug activé, ça plante à partir du tag 2.5.3 du plugin et chacune des versions qui suivent.

Dès qu'on reprend 2.5.2, ça marche ça compile bien.
Dès qu'on désactive Xdebug ça marche aussi jusqu'en master.

Il est donc possible que plusieurs des erreurs que j'ai signalé dans mes tickets précédents étaient liées… Il faudra que je reteste les libs plus récentes que j'essayais de compiler sans Xdebug et/ou en 2.5.2.

Cette fois-ci j'ai un truc reproductible ! :D J'ai utilisé le squelette-thème Photographe qui est public là : https://git.spip.net/spip-contrib-squelettes/photographe Avec un PHP qui a Xdebug activé, ça plante à partir du tag 2.5.3 du plugin et chacune des versions qui suivent. Dès qu'on reprend 2.5.2, ça marche ça compile bien. Dès qu'on désactive Xdebug ça marche aussi jusqu'en master. Il est donc possible que plusieurs des erreurs que j'ai signalé dans mes tickets précédents étaient liées… Il faudra que je reteste les libs plus récentes que j'essayais de compiler sans Xdebug et/ou en 2.5.2.
Owner

Je vais voir si je reproduis, mais quelques infos en plus comme la version PHP, voire le log de l'erreur PHP ça serait pas si mal :)

Je vais voir si je reproduis, mais quelques infos en plus comme la version PHP, voire le log de l'erreur PHP ça serait pas si mal :)

Alors c'est PHP Version 7.2.34-9+ubuntu20.04.1+deb.sury.org+1

Et les erreurs sont juste visibles dans les logs d'apache du coup, avec des choses comme :

[Sun Jan 31 00:23:24.250485 2021] [php7:notice] [pid 342508] [client 127.0.0.1:33922] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 211225728 bytes) in /home/vincent/travail/git/spip/scssphp/lib/scssphp/src/Compiler.php on line 5896, referer: http://localhost/~vincent/photos/?var_mode=css

suivi d'une stack trace de 3000km de long avec tout le détail du moindre paramètre (xdebug qui décompose tout je suppose).

Alors c'est PHP Version 7.2.34-9+ubuntu20.04.1+deb.sury.org+1 Et les erreurs sont juste visibles dans les logs d'apache du coup, avec des choses comme : ``` [Sun Jan 31 00:23:24.250485 2021] [php7:notice] [pid 342508] [client 127.0.0.1:33922] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 211225728 bytes) in /home/vincent/travail/git/spip/scssphp/lib/scssphp/src/Compiler.php on line 5896, referer: http://localhost/~vincent/photos/?var_mode=css ``` suivi d'une stack trace de 3000km de long avec tout le détail du moindre paramètre (xdebug qui décompose tout je suppose).
pierr0t closed this issue 10 months ago
Collaborator

c'est normal @pierr0t cette fermeture sans aucun commentaire?

c'est normal @pierr0t cette fermeture sans aucun commentaire?
Collaborator

Non absolument pas, j'ai commencé un commentaire (le pbm soulevé semble être un MEMORY_LIMIT de PHP à 128M peut-être simplement insuffisant) mais ne connaissant pas le contexte j'ai décidé de m'abstenir et à côté du bouton "Créer un commentaire" il y avait le bouton "Fermer" et sur le moment j'ai juste pensé que ça refermait le formulaire et bien apparemment non, ça ferme le ticket .... désolé. Je réouvre immédiatement.

Non absolument pas, j'ai commencé un commentaire (le pbm soulevé semble être un MEMORY_LIMIT de PHP à 128M peut-être simplement insuffisant) mais ne connaissant pas le contexte j'ai décidé de m'abstenir et à côté du bouton "Créer un commentaire" il y avait le bouton "Fermer" et sur le moment j'ai juste pensé que ça refermait le formulaire et bien apparemment non, ça ferme le ticket .... désolé. Je réouvre immédiatement.
pierr0t reopened this issue 10 months ago
Owner

Je passe sur la blague "un truc reproductible" sans plus de détail.

Je viens donc de passer 1/2H à installer tout le bouzin pour arriver enfin à avoir toute la configuration qui marche (il fallait donc le squelettes ET le thème), pour voir que ça embarque donc pléthore de frameworks.

Bref, j'ai en local la version à jour de ScssPHP 2.8., SPIP 3.3, PHP 7.2.34 AVEC Xdebug et tout a compilé du premier coup.

Donc en effet commoe @pierr0t l'a supposé, c'est a priori juste un soucis de mémoire liée à l'utilisation de XDebug.
Et de la même façon qu'il faut augmenter le nombre de recursions maxis si on veut utiliser Saisies avec XDebug, il faut visiblement ici augmenter la mémoire.

Mais aucun bug dans le plugin.

Je passe sur la blague "un truc reproductible" sans plus de détail. Je viens donc de passer 1/2H à installer tout le bouzin pour arriver enfin à avoir toute la configuration qui marche (il fallait donc le squelettes ET le thème), pour voir que ça embarque donc pléthore de frameworks. Bref, j'ai en local la version à jour de ScssPHP 2.8., SPIP 3.3, PHP 7.2.34 AVEC Xdebug et tout a compilé du premier coup. Donc en effet commoe @pierr0t l'a supposé, c'est a priori juste un soucis de mémoire liée à l'utilisation de XDebug. Et de la même façon qu'il faut augmenter le nombre de recursions maxis si on veut utiliser Saisies avec XDebug, il faut visiblement ici augmenter la mémoire. Mais aucun bug dans le plugin.
cerdic closed this issue 10 months ago

Alors merci d'avoir cherché mais je ne comprends pas le ton agacé.

Pourquoi alors ça marche sur toutes les versions 1.X + toutes les versions 2.X jusqu'à 2.5.2 ?

Changer la mémoire ne change rien chez moi, c'est la première chose que j'ai faite, je l'avais déjà déjà augmenté à 512 puis à plus encore et la conséquence c'est que ça ne fait QUE : tourner encore plus longtemps à l infini. Ça ne résout rien du tout chez moi et même c'est le contraire : avec 128 ça finit pas faire une page blanche, alors qu'avec 512 et plus ça tourne à l'infini sans plus jamais s'arrêter. Tout ça pour compiler juste 200Ko de SCSS qui marchaient pourtant très bien, c'est forcément bizarre et hors norme d'avoir besoin de ça.

Donc bah si ya bien un problème propre au plugin : ça compilait avec seulement 128Mo de mémoire alloué avec plein de versions de SCSSPHP et tout d'un coup bam, même en quadruplant et plus, ça tourne à l'infini…

Mettre à jour un plugin n'est pas censé nécessiter un plus que quadruplage de la mémoire pour fonctionner de nouveau non ? (et encore ça, non ça ne marche pas même en augmentant)
Surtout que c'est entre 2.5.2 et 2.5.3 donc version mineure, donc pas une refonte du moteur qui tout d'un coup se mettrait à utiliser mille fois plus de fonctions.

Quant à l'installation je ne vois pas où je n'aurais pas été clair : j'ai donné le lien de quoi installer, qui contient deux dossiers dedans, bah faut juste installer ce que j'ai mis en lien quoi, ni plus ni moins, ya pas de piège.

"Pléthore de frameworks" : euh trois, littéralement trois. Et qui ne sont que des micro frameworks qui ne font qu'une chose précise : le nombre de différents importe peu, l'addition est plus petite que Bootstrap4 et plein d'autres "tout-en-un". Ça fait vraiment com agacé du genre "t'as qu'à pas utiliser ça, ça marcherait mieux" alors qu'aucun rapport, ce n'est pas plus gros que n'importe quel autre truc.

Le fait est que ça marche parfaitement depuis des années avec carrément peu de mémoire 128Mo et xdebug bien activé, et tout d'un coup depuis l'une des mises à jour (2.5.3 précisément) ça ne marche plus. Donc ya bien une "fuite" quelque part qui fait que ça merdouille à ce point… Quelque chsoe qui à partir de ce commit : 3b0d87d70b fait débloquer la mémoire si xdebug présent…

Je viens de refaire plein de tests, en changeant la mémoire, la version du plugin, etc… c'est toujours pareil :

PHP 7.2, SPIP 3.2, avec seulement 128 de mémoire aloué :

  • var_mode=css pour forcer le recalcule SCSS
  • avec xdebug activé + plugin 2.5.2 ou inférieur
  • à peine 50% du CPU utilisé
  • aucune différence si xdebug désactivé, ça met le même temps et même CPU
  • pendant 1 seconde maxi, rechargement immédiat
  • et tout le thème entier est compilé et la page rechargée !

Si 2.5.3 et supérieur avec xdebug activé :

  • 100% du CPU sur le processus Apache (PHP à priori)
  • si 128 de mémoire alouée, ça tourne longtemps puis page blanche et plein de stack trace dans logs apache
  • si 512 alors ça tourne à l'infini avec 100% du CPU
  • exactement pareil avec 1024 et plus…

La différence de comportement est tellement disproportionnée entre les deux versions 2.5.2 et 2.5.3, qu'il y a forcément un truc à comprendre, même si ce truc ce serait un point que je n'aurais pas réussi à définir et qui serait propre à mon install (mais quoi dans ce cas).

Alors merci d'avoir cherché mais je ne comprends pas le ton agacé. Pourquoi alors ça marche sur toutes les versions 1.X + toutes les versions 2.X jusqu'à 2.5.2 ? Changer la mémoire ne change rien chez moi, c'est la première chose que j'ai faite, je l'avais *déjà* déjà augmenté à 512 puis à plus encore et la conséquence c'est que ça ne fait QUE : tourner encore plus longtemps à l infini. Ça ne résout rien du tout chez moi et même c'est le contraire : avec 128 ça finit pas faire une page blanche, alors qu'avec 512 et plus ça tourne à l'infini sans plus jamais s'arrêter. Tout ça pour compiler juste 200Ko de SCSS qui marchaient pourtant très bien, c'est forcément bizarre et hors norme d'avoir besoin de ça. Donc bah si ya bien un problème propre au plugin : ça compilait avec *seulement* 128Mo de mémoire alloué avec plein de versions de SCSSPHP et tout d'un coup bam, même en *quadruplant* et plus, ça tourne à l'infini… Mettre à jour un plugin n'est pas censé nécessiter un plus que quadruplage de la mémoire pour fonctionner de nouveau non ? (et encore ça, non ça ne marche pas même en augmentant) Surtout que c'est entre 2.5.2 et 2.5.3 donc version mineure, donc pas une refonte du moteur qui tout d'un coup se mettrait à utiliser mille fois plus de fonctions. Quant à l'installation je ne vois pas où je n'aurais pas été clair : j'ai donné le lien de quoi installer, qui contient deux dossiers dedans, bah faut juste installer ce que j'ai mis en lien quoi, ni plus ni moins, ya pas de piège. "Pléthore de frameworks" : euh trois, littéralement trois. Et qui ne sont que des *micro* frameworks qui ne font qu'une chose précise : le nombre de différents importe peu, l'addition est plus petite que Bootstrap4 et plein d'autres "tout-en-un". Ça fait vraiment com agacé du genre "t'as qu'à pas utiliser ça, ça marcherait mieux" alors qu'aucun rapport, ce n'est pas plus gros que n'importe quel autre truc. Le fait est que ça marche parfaitement depuis des années avec carrément peu de mémoire 128Mo et xdebug bien activé, et tout d'un coup depuis l'une des mises à jour (2.5.3 précisément) ça ne marche plus. Donc ya bien une "fuite" quelque part qui fait que ça merdouille à ce point… Quelque chsoe qui à partir de ce commit : https://git.spip.net/spip-contrib-extensions/scssphp/commit/3b0d87d70b93aadac6460be8ec58ab755e5deb83 fait débloquer la mémoire si xdebug présent… Je viens de refaire plein de tests, en changeant la mémoire, la version du plugin, etc… c'est toujours pareil : PHP 7.2, SPIP 3.2, avec *seulement* 128 de mémoire aloué : - var_mode=css pour forcer le recalcule SCSS - avec xdebug activé + plugin 2.5.2 ou inférieur - à peine 50% du CPU utilisé - aucune différence si xdebug désactivé, ça met le même temps et même CPU - pendant 1 seconde maxi, rechargement immédiat - et tout le thème entier est compilé et la page rechargée ! Si 2.5.3 et supérieur avec xdebug activé : - 100% du CPU sur le processus Apache (PHP à priori) - si 128 de mémoire alouée, ça tourne longtemps puis page blanche et plein de stack trace dans logs apache - si 512 alors ça tourne à l'infini avec 100% du CPU - exactement pareil avec 1024 et plus… La différence de comportement est tellement disproportionnée entre les deux versions 2.5.2 et 2.5.3, qu'il y a forcément un truc à comprendre, même si ce truc ce serait un point que je n'aurais pas réussi à définir et qui serait propre à mon install (mais quoi dans ce cas). ![](https://git.spip.net/attachments/b8a8e6d4-3fb5-4f1c-a371-755ab4d2c670)

À tout hasard je viens de compiler avec spip-cli : ça marche parfaitement en 2.8 avec Xdebug activé ET toujours que 128 de mémoire, avec résultat instantanné. Donc pour ce point là de xdebug, le cli n'aide pas, puisque la page blanche (128) ou la fuite infinie à 100% de CPU (512 et plus), ne se produit donc que si en page web avec var_mode=css (et si >= 2.5.3 uniquement).

À tout hasard je viens de compiler avec spip-cli : ça marche parfaitement en 2.8 avec Xdebug activé ET toujours que 128 de mémoire, avec résultat instantanné. Donc pour ce point là de xdebug, le cli n'aide pas, puisque la page blanche (128) ou la fuite infinie à 100% de CPU (512 et plus), ne se produit donc que si en page web avec var_mode=css (et si >= 2.5.3 uniquement).
Owner

Il y a peut être un truc à comprendre, mais :

  • même avec un test unitaire de 10 lignes de code, les intrications et imbrications du compilateur sont telles que c'est parfois hard core pour comprendre
  • par suite, debuguer sur la compilation complète de un ou plusieurs frameworks c'est mission totalement impossible
  • je viens d'essayer tous les tags+le master du plugin scssphp depuis la version 2.5.2 et tout compile à l'identique dans tous les cas avec un temps de ~2s environ
2021-02-02 16:50:21 127.0.0.1 (pid 78729) :Pub:info: scss_compile  compile plugins/bau/photographe/theme/css/theme.scss :: 2 113.254 ms

Partant de là comme je ne reproduis rien il y a sans doute quelque chose lié à ta config xdebug (comme par exemple l'option profiling activée) ?

Pour info, on a déjà expérimenté des temps de compilation super long sur les postes de dev à cause de xdebug, et il y a un palliatif qui permet en plus d'exclure la compilation des traces
0ee4fe7210

Ça pourra te dépanner.

Mais pour le reste je vois pas quoi faire de plus

Il y a peut être un truc à comprendre, mais : - même avec un test unitaire de 10 lignes de code, les intrications et imbrications du compilateur sont telles que c'est parfois hard core pour comprendre - par suite, debuguer sur la compilation complète de un ou plusieurs frameworks c'est mission totalement impossible - je viens d'essayer tous les tags+le master du plugin scssphp depuis la version 2.5.2 et tout compile à l'identique dans tous les cas avec un temps de ~2s environ ``` 2021-02-02 16:50:21 127.0.0.1 (pid 78729) :Pub:info: scss_compile compile plugins/bau/photographe/theme/css/theme.scss :: 2 113.254 ms ``` Partant de là comme je ne reproduis rien il y a sans doute quelque chose lié à ta config xdebug (comme par exemple l'option profiling activée) ? Pour info, on a déjà expérimenté des temps de compilation super long sur les postes de dev à cause de xdebug, et il y a un palliatif qui permet en plus d'exclure la compilation des traces https://git.spip.net/spip-contrib-extensions/scssphp/commit/0ee4fe721063ea24c54958294710fbe0755b55c5 Ça pourra te dépanner. Mais pour le reste je vois pas quoi faire de plus
Owner

attention : en général c'est pas le meme php.ini en cli et en module apache, et du coup le xdebug est pas actif en cli

attention : en général c'est pas le meme php.ini en cli et en module apache, et du coup le xdebug est pas actif en cli

Ooook merci j'avance ! alors du coup je suis allé voir le détail des options xdebug efectivement, j'en ai plusieurs donc je les ai toutes testées seules une par une et c'est donc la ligne :
xdebug.var_display_max_depth=-1
qui nique tout… enfin toujours à partir de 2.5.3 seulement, ne pose pas de problème ni avec saisies ni avec les versions d'avant de scssphp

Et sinon l'ensemble des options

zend_extension=xdebug.so
xdebug.max_nesting_level=500
xdebug.var_display_max_children=-1
xdebug.var_display_max_data=-1
xdebug.var_display_max_depth=-1
Ooook merci j'avance ! alors du coup je suis allé voir le détail des options xdebug efectivement, j'en ai plusieurs donc je les ai toutes testées seules une par une et c'est donc la ligne : `xdebug.var_display_max_depth=-1` qui nique tout… enfin toujours *à partir de 2.5.3 seulement*, ne pose pas de problème ni avec saisies ni avec les versions d'avant de scssphp Et sinon l'ensemble des options ``` zend_extension=xdebug.so xdebug.max_nesting_level=500 xdebug.var_display_max_children=-1 xdebug.var_display_max_data=-1 xdebug.var_display_max_depth=-1 ```
Owner

ah en effet ce var_display_max_depth doit faire tomber dans une boucle sans fin d'affichage car les structures internes comportent en effet des pointeurs recursifs.

Ce qui peut se passer, c'est que lors d'une Exception interne xdebug essaye de construire une trace et du fait de ce max-depth il plante la mémoire.

Cette exception est par ailleurs non visible, car catchée ce qui arrive sur du reparsing.
Dans certains cas de selecteur calculé on tombe sur quelque chose qui nécessite possiblement un reparsing, ce que l'on tente, en catchant une éventuelle exception.

Mais avec ton réglage de xdebug, ça ne passe plus. Et il est possible qu'on ait ajouté des cas de reparsing dans les commits en cause (je sais qu'on a ajouté des cas, mais je retrouve pas rapidement quand et où, et il y a une pelleté de commits dans le compilateur correspondant à ce simple commit du plugin).

Donc bref, limite ton max-depth à une valeur raisonable (par défaut c'est 3 et -1=1024) et tout ira mieux pour tout le monde !

ah en effet ce var_display_max_depth doit faire tomber dans une boucle sans fin d'affichage car les structures internes comportent en effet des pointeurs recursifs. Ce qui peut se passer, c'est que lors d'une Exception interne xdebug essaye de construire une trace et du fait de ce max-depth il plante la mémoire. Cette exception est par ailleurs non visible, car catchée ce qui arrive sur du reparsing. Dans certains cas de selecteur calculé on tombe sur quelque chose qui nécessite possiblement un reparsing, ce que l'on tente, en catchant une éventuelle exception. Mais avec ton réglage de xdebug, ça ne passe plus. Et il est possible qu'on ait ajouté des cas de reparsing dans les commits en cause (je sais qu'on a ajouté des cas, mais je retrouve pas rapidement quand et où, et il y a une pelleté de commits dans le compilateur correspondant à ce simple commit du plugin). Donc bref, limite ton max-depth à une valeur raisonable (par défaut c'est 3 et -1=1024) et tout ira mieux pour tout le monde !
Sign in to join this conversation.
No Label
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.