Les cas d’erreur

Si il y a un reproche à faire aux logiciels de linux, c’est la gestion des erreurs. Il y a l’outil magnifique qui est syslog, mais je fais plutot référence au style de codage: le programmeur s’attend quasiment à avoir des données dans le bon format en entrée. Tout débutant débute comme cela car déjà on n’y pense pas forcément, mais en plus la gestion des erreurs peut être chiante, surtout une bonne gestion d’erreur qui consiste au moins à afficher l’erreur, voire la raison dans le meilleur des cas.

Dans le pire des cas, on se retrouve avec une erreur de segmentation. Cela m’est arrivé une fois et si j’en parle aujourd’hui c’est parce que cela ne concerne pas un logiciel inconnu mais un outil de base du système: update-mime-database. Pour résumer, ce programme s’occupe de mettre à jour la base de données des types MIME connus. Ceci fonctionne à base de fichiers XML qui sont en gros analysés et sauvegardés dans un fichier binaire. Rien de bien sorcier, sauf qu’un fichier XML a pour vocation d’être édité à la main, et malgré avoir rigoureusement suivi le tutorial pour ajouter un nouveau type MIME, le programme plante lamentablement sur un Segmentation fault. Un programme critique du système qui plante à cause d’un XML bien formé et qui ne donne pas la raison de plantage…

Déjà dans le tutorial (ce n’est pas le lien exact, je ne retrouve plus le tutorial), on voit que l’on est dans la rubrique Administrator du site de Gnome, on est plus dans la branche Users, donc la réaction classique: « tu es un mauvais admin, bla bla bla », et donne l’impression que cela ne concerne pas les utilisateurs. Passons… Je débogue le programme… c’est ça qui est bien avec l’open source, les sources sont disponibles, et miracle, elles se compilent sans complication.

Déjà ce programme est juste une grosse blague: un fichier immense (3500+ lignes), écrit par Thomas Leonard et bien sûr « with ABSOLUTELY NO WARRANTY » et ça se voit. Il a été écrit en 2003, on peut dire que cette absence de structure est dû au faible génie logiciel de l’époque, c’est pardonnable (quoi que). Hors de question de plonger dans ces 3500 lignes, une compilation avec les options de débogage et j’aurais la ligne du « Segmentation fault ». Je fais donc tout cela, j’utilise Valgrind aussi tant qu’à faire, je trouve la ligne correspondante, sans comprendre pourquoi je la corrige, juste un simple test à ajouter (cf le patch) puis j’ai créé un bug report avec son patch (sans fournir de testcase dans l’immédiat car je pensais que ça allait sauter aux yeux des développeurs xD).

Évidemment il n’y avait plus de développeurs, juste le mainteneur (qui est quand même un dév), et il a mieux corrigé le problème avec l’ajout d’un message d’erreur. J’ai pu ainsi connaître la raison du plantage: il manquait une balise XML dans le fichier… WTF. C’est la base du XML pourtant d’être éditable par un humain et donc sujet à des erreurs ou des oublis (je précise que le XML était bien formé, ce n’est pas une balise fermante ou ouvrante qui manquait, mais une balise apparemment obligatoire).

A vrai dire, des fois il y a des bugs gros comme une montagne, et montre tout simplement que du code critique est commité et est passé en production (release) sans jamais avoir été testé. Exemple classique: bumblebee, qui va certainement en devenir une référence en la matière. En effet, c’est le script d’installation qui possédait un bug, un espace supplémentaire a été inséré dans une commande de suppression qui provoquait la suppression complète du dossier /usr au lieu d’un simple fichier.

C’est la dure vérité des projets non financé: certains (impossible de sortir des chiffres) développeurs s’en foutent et release leur logiciel en comptant sur la communauté pour remonter les bugs. Ils ne se reliront pas avant de commiter, ils ne testeront pas (dans le cas de bumblebee peut-être qu’il ne pouvait pas car il fallait une carte graphique nvidia), il y a personne pour assurer la qualité, c’est à vos risques et périls, ce n’est pas pour rien qu’il est rappelé dans tout logiciel qu’il est distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Ceci dit, il n’y a aussi aucune garantie pour les logiciels propriétaire.

Le pire est que c’est pareil avec la release de GTK+2… un gros projet avec du monde derrière. J’ai eu le malheur de devoir compiler GTK+2 et j’ai téléchargé l’archive version 2.24.5 (daté du 16-Jun-2011) qui est donc la dernière version stable pour la version 2 (la 3 étant sortie depuis un moment)… et au moment de la compilation… grosse blague, je retombe sur un vieux bug censé être corrigé en avril 2011…

Plus précisément, la correction a été « pushed ». C’est à dire que la proposition de patch a été faites, mais que personne n’a voulu l’intégrer. Le rapport de bug indique que cela provient du linker et que windows serait fautif, pour ma part je suis sur linux et j’ai eu ce problème. En fait ça revient à ce que je dis depuis toujours: à partir du moment que les développeurs ne rencontrent pas le bug alors il n’y a rien qui change, ou alors lentement.

Ceci dit, coté logiciels propriétaires ce n’est pas mieux, voire pire… ou meilleur, c’est comme partout, cela dépend des personnes qui s’occupent d’un projet.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :