Pas facile des fois la programmation. Actuellement je m'arrache les cheveux et j'avale des aspirines.

Premier tube d'aspirine

Sur le nouveau validateur d'Etna tout d'abord, où j'ai des foutus leaks qui se cachent je ne sais où. Ça fait plusieurs jours que je tente de les débusquer. J'ai même fini par faire un petit tour sous windows pour faire bosser le déboggeur de Visual Studio (oui parce que gdb, c'est un peu de la merde...). Et faut savoir que quand je vais debogger sous windows, c'est vraiment l'ultime recours, après avoir tout tenter (oui parce que bosser sous windows, ça m'irrite pas qu'un peu tellement c'est une daube ce système...). Au final, j'en ai éradiqué certains, et je pense avoir trouvé les derniers aujourd'hui. Ou disons, je pense avoir trouvé l'origine de ces leaks : des nsString qui veulent pas mourir. Mais je ne suis pas encore arrivé à comprendre pourquoi ces p**ins de nsString restent en vie. J'ai beau retourner mon code dans tout les sens, ça veut pas le faire. Du coup, je commence à me demander si ce ne sont pas ces nsString (qui font parti de l'API Mozilla) qui buggent quelque part.

Deuxième tube d'aspirine

Mais apparemment, mon destin est d'avaler encore plus d'aspirines, parce que j'ai aussi un bug du même genre dans Jelix, ce genre de bug où tu passes des heures à comprendre le pourquoi du comment... Ainsi, dans Jelix, pour l'authentification, je met un objet en session. Je n'inclus pas systématiquement la classe (A) de cet objet à chaque exécution, tous les projets n'utilisant pas l'authentification. Donc à chaque exécution, PHP charge l'objet, mais essaye d'abord de trouver la classe A. Comme elle n'est pas définie, il invoque l'autoload de Jelix, qui charge le bon fichier A.class.php. Le truc à savoir c'est que cette classe A hérite d'une autre classe B, et que le fichier A.class.php fait un include du fichier B.class.php. Donc à priori, PHP a toutes les billes en main pour charger l'objet qui est en session à chaque requête. Et bien non. L'autoload est appelé une seconde fois pour la classe B. Ce qui veut dire que PHP ne connait pas B après le chargement de A.class.php. Et comme mon autoload ne sait pas où aller chercher cette classe B, une erreur d'exécution apparait. Le pire dans tout ça, c'est que cela n'arrive pas tout le temps ! Apparemment cette erreur apparait aléatoirement ! Des fois ça fonctionnent. Des fois ça ne fonctionnent pas. Bon, pour contourner ce bug, il suffirait apparemment de faire en sorte que mon autoload sache où trouver le fichier de la classe B. Mais ça reste rageant de ne pas comprendre pourquoi ce bug !

  • Première conclusion : je suis de plus en plus certain qu'il y a un bug dans PHP au niveau des includes au cours d'un autoload. Ce ne serait pas la première fois que ça arrive.
  • Deuxième conclusion : Il faudrait forker PHP. Plus je vois comment est géré le projet PHP, plus je comprend pourquoi il y a toujours pleins de petits bugs à la con dans PHP, et pourquoi il y a plein de trucs pas logiques dans l'API (Non, ce n'est pas pour autant que je ferais du python ou du ruby ;-) ). Bon, le seul souci, c'est que je n'ai plus de place dans ma ToDo list. Des volontaires ?

PS : je viens enfin de trouver le pourquoi du comment du bug dans Jelix : il apparait quand on utilise l'extension APC. Celle-ci déconne à plein tube. Voir les explications sur le ticket