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.

Les icones ?

Je ne vais pas me plaindre de tout et n’importe quoi sur linux. Par exemple pour les problèmes de drivers, on n’y peut rien. J’ai quand même bien pris soin de choisir une nvidia pour avoir le moins de problème possible et surtout pouvoir jouer. Pour les choix de mise à jour buggée de logiciel car cela n’a pas été testé sur toutes les plateforme, on n’y peut rien aussi… manque de testeur pour ma distribution on va dire. Et à présent mon PC plante quand j’agrandis une fenêtre précise, mais je n’y peux rien, j’ai quand même le choix de downgrader à une ancienne version du logiciel en question (le serveur X). Mais avant que j’en arrive à faire cela, mon pc plante, il redémarre… et surprise, mes icônes de bureau et celles de dolphin ont changé.

J’ai pensé à un problème de fichier de configuration tronqué à cause de l’arrêt « brutal » du système. Et en fait non, impossible de retrouver les icônes originales, et mon thème dans les préférences indiquait qu’il avait toujours eu ces icônes là. Je restaure alors le paquet correspondant au thème et cela ne marche pas… cela m’a vite saoulé d’avoir des icônes ultra moches (car finalement cela joue beaucoup sur l’expérience utilisateur), et j’ai installé un nouveau thème.

Quoi qu’il en soit, c’était bien drôle de me retrouver avec un thème avec seulement les icônes de différentes. Ce n’était pas la fin du monde, mais j’étais étonné que le thème fut touché alors qu’aucune écriture ne devait avoir lieu (mais qui était peut-être en cache d’écriture?).

Dans le même genre, mais cette fois-ci plus lié à la distribution, les icônes « Suivant » et « Précédent » de Firefox 3.6 avaient disparu, les boutons étaient toujours là mais sans icônes, à la mise à jour suivante ils sont revenus. Bug pas gênant mais rigolo.