Écriture du fuzzer

Mon fuzzer ayant trouvé pas mal de bugs, je les corrige au fur et à mesure en tentant de généraliser les corrections. Après une semaine, je suis assez fier de moi, l'ensemble a l'air assez robuste. Sauf que ce n'est qu'une impression : je n'avais en fait que passer la première étape.

La seconde est l'épuisement des ressources (processeur et/ou mémoire). En général, c'est une boucle un peu trop longue (à partir de dix mille itérations) qui monopolise les ressources. Pour guetter l'utilisation excessive du processeur : je mesure le temps du traitement, ce qui m'a permis de corriger un autre bug.

Plantage de Python

Quand enfin je me suis mis à travailler sur l'épuisement de la mémoire, j'ai commencé à déchanter. Pour commencer, j'ai écrit un outil permettant d'exécuter une fonction avec une quantité de mémoire limitée. Malheureusement, en relançant mes tests j'ai constaté une erreur de segmentation. Oups ! Quand Python (et non mon programme) plante c'est très mauvais signe. Le temps de télécharger les sources de Python et de le recompiler, j'isole le bug : c'est l'allocation de mémoire pour la création d'une exception qui échoue.

Je corrige cette erreur et fier comme un coq, je relance encore une fois les tests persuadé que tout va fonctionner comme sur des roulettes. Rebelote : plantage d'une autre partie du code de Python (calcul sur les entiers longs). Quand on trouve des bugs dans Python après 3h du mat', je pense qu'il est grand temps d'aller au lit. Quand j'aurai un peu mieux cerné le problème, je décrirai un peu mieux le problème.

Tout ça pour dire que la quête du programme parfait est un chemin long et sinueux. Cette expérience montre également que les logiciels qu'on utilise sur nos ordinateurs sont robustes en apparence mais deviennent instables quand on commence à les chatouiller...