URL:     https://linuxfr.org/news/la-voiture-allergique-a-la-glace-a-la-vanille-et-autres-bugs
Title:   La voiture allergique à la glace à la vanille, et autres bugs
Authors: Collectif
        Ysabeau, pulkomandy, Benoît Sibaud, teoB, olivierweb, Snark, palm123, yPhil, ariasuni, Tonton Th, legranblon, Pierre Maziere, BAud, Vincent-Xavier JUMEL et Christophe ---
Date:    2020-05-01T11:59:57+02:00
License: CC By-SA
Tags:    bogue
Score:   3


Une liste de bugs étonnants. Pour certains, il y a suffisamment d’informations pour remonter à la source et on peut s’assurer qu’il s’agit de vrais bugs. Pour d’autres, différentes versions circulent, les origines se perdent trop loin dans le passé, et on s’approche plus de la légende urbaine que de l’histoire vraie. L’histoire de la voiture allergique à la glace à la vanille, quant à elle, n’est pas à proprement parler un bug informatique, mais elle est intéressante.



Ce qu’il faut néanmoins retenir de l’ensemble de ces histoires, vraies ou fausses, c’est qu’une corrélation, même douteuse, même étonnante, est un indice qu’il convient d’examiner avant de le rejeter, et peut-être aussi, que le problème ne vient pas systématiquement de l’interface entre la chaise et le clavier (ou de son chat).



Elles sont tirées en partie du site en anglais, [Software Folklore](http://beza1e1.tuxen.de/lore/index.html), et, plutôt que de les traduire intégralement, on a pensé que vous en résumer quelques-unes pouvait être plus intéressant en permettant de vous donner un échantillon assez varié (bon, soyons tout à fait honnêtes, personne n’était motivé pour se lancer dans des traductions complètes et ça épargne certaines longueurs des textes originaux).

----

[Software Folklore](http://beza1e1.tuxen.de/lore/index.html)

----

La réponse d’Andreas Zwinkau à la demande de palm123 de traduire ces histoires :



> I'm not the author and in most cases the author is unknown. So feel free to translate them.
> Be careful with the external links though. There you need to ask the original author.



_Je ne suis pas l’auteur et, dans la plupart des cas, l’auteur est inconnu. N’hésitez donc pas à les traduire. Cela dit, faites attention aux liens externes, là vous aurez besoin de demander la permission à l’auteur._



#La piste du plantage de la Xbox



Lors de la conception de l’un des tous premiers jeux de la console de jeux Xbox, lors des tests, qui se déroulaient automatiquement la nuit, inévitablement une Xbox sur les trois plantait. Le jeu, évidemment, fonctionnait sans problème sur la machine de l’ingénieur. Une intense recherche de chasse au bogue n’avait abouti à rien : le code était tout à fait propre et sans bavure.



Serait-ce le matériel ? Les câbles électriques étaient impeccables donc hors de cause, idem pour les contrôleurs. Décision fût prise d’essayer autre chose : mélanger machines et câbles, et, au matin, replantage d’une machine.



En désespoir de cause : le concepteur décide de passer la nuit avec les machines ! Bingo, au matin un rayon du soleil levant tapant sur une des machines qui plante illico. C’était un problème de carte graphique qui tombait en panne au-delà d’une certaine température.



Affaire résolue.



[Version originale.](http://beza1e1.tuxen.de/lore/table_crashes_xbox.html)



Une histoire étrangement similaire est racontée, près de 20 ans plus tôt, dans [la lettre de BeOS](https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-22.html), sous le titre _A testing fairy tale_ (un conte de fées de test). Il est probable que la version ci-dessus est une variante modernisée de cette histoire.


Cette fois-ci, il s’agit de tests sur un lecteur de disquettes. Tout semble bien fonctionner pour les développeurs, mais dans le labo de test, il y a toutes les nuits un échec au bout d’un certain temps sur des tests d’écriture sur les disquettes. Le responsable des tests ne parvient jamais à reproduire le problème en journée, et un seul lecteur de disquettes semble poser problème. Mais, impossible de trouver une piste sur ce qui pouvait causer le dysfonctionnement.



L’un des ingénieurs travaillant sur ce lecteur de disquettes finit par rester toute la nuit (avec des expressos plutôt que des boissons énergisantes, cette fois-ci) pour observer le problème et tenter de le comprendre. Les tests fonctionnent sans problème pendant toute la nuit, et le soleil finit par se lever. Un rayon de soleil éclaire le lecteur de disquettes, et, soudain, le problème se reproduit !



Le lecteur en question n’était pas mis dans un boîtier, et le capteur servant à détecter si la disquette est protégée en écriture était un capteur optique (avec normalement une DEL éclairant ce dernier à travers un trou dans la disquette, le trou n’étant ouvert que pour les disquettes protégées).



Le rayon de soleil éclairant le capteur indiquait au lecteur de disquettes que la disquette était soudainement devenue protégée en écriture, provocant le problème.



# Les vrais programmeurs écrivent en Fortran (en fait non)



Cette histoire remonte à l’époque où chaque machine était programmée avec son propre code, pas en assembleur, ni en Fortran mais directement dans un langage binaire qui lui était propre et ne pouvait être utilisé pour une autre machine. À l’époque, les machines étaient un système à tambour avec des tubes à vides (voir [l’interview hommage de France Allen](https://linuxfr.org/news/hommage-a-frances-allen) en complément).



Dans cette histoire, on a affaire à un programmeur « à l’ancienne » qui n’aimait pas les compilateurs et avait écrit en hexadécimal le programme d’ordinateur le plus populaire du constructeur d’ordinateurs chez qui il travaillait. Il devait donc réécrire le programme du jeu de « blackjack » pour une nouvelle machine, la RPC-4000. À l’époque, chaque instruction était suivie d’un « `GOTO` » ! Le code devait localiser les instructions sur le tambour, et quand une était finie, il fallait arriver à la « tête de lecture » suivante. On avait mis en place un assembleur d’optimisation que ledit programmeur refusait d’utiliser au motif qu’on ne savait pas trop où il allait intervenir. Il expliquait qu’il fallait utiliser des constantes séparées. En fait, il écrivait la valeur numérique de chaque opération et lui attribuait une adresse fixe sur le tambour. C’était efficace et rapide, mais pas facile à modifier pour quelqu’un d’autre.



Donc il termine le programme « blackjack ». Sauf que, le département des ventes de l’entreprise lui demande de le modifier. En effet, ils voulaient qu’il y ait un commutateur de façon à pouvoir modifier les cotes pour que les clients gagnent (le programme utilisait un générateur de nombres aléatoires). Le programmeur refuse, arguant d’une atteinte à son intégrité. Il fait finalement le travail mais, quand le commutateur est actionné, la machine gagne à chaque fois.



Son successeur regarde le code, trouve une boucle qui n’avait pas de test, aucun. Sans doute une boucle fermée. Le code tirait l’instruction du registre de la machine et en ajoutait une qui avait sa propre adresse, puis il la rangeait. La boucle avait pour objet de prendre en compte le temps supplémentaire pris par l’opération puis de placer la suivante juste sous la tête de lecture du tambour. Ce que le programmeur précédent avait fait, c’était de localiser les emplacements les plus importants sur lesquels les instructions arrivaient. Arrivé à la dernière, il se passait un débordement (overflow), du coup la série d’instructions suivante devenait « jump » et, en toute logique, l’instruction suivante était à l’adresse zéro.



[Version originale.](http://beza1e1.tuxen.de/lore/story_of_mel.html ou http://catb.org/jargon/html/story-of-mel.html)



#OpenOffice n’imprime pas le mardi



Dans une ancienne version d’OpenOffice, l’impression pouvait échouer. Il ne semblait pas y avoir de logique, le problème arrivait de temps en temps puis disparaissait de lui-même sans raison apparente. Jusqu’à que l’épouse d’un informaticien remarque quelque chose : le problème se produit tous les mardi (Tuesday) et jamais les autres jours. Pourquoi le mardi ?



On imagine le dialogue, l’époux qui demande à sa femme si on peut tester, elle qui lui répond « non parce qu’on est mercredi » et l’impression à partir d’OpenOffice fonctionne sans problème le mercredi. Passé un moment d’incrédulité et après quelques essais, il faut bien se rendre à l’évidence : OpenOffice n’imprime pas le mardi.



Cela venait d’un programme appelé « file » (fichier), un utilitaire UNIX qui utilise des motifs pour détecter les types de fichiers. Cet outil utilise une liste de motifs à comparer avec certains octets dans le fichier à analyser. Ainsi si un fichier commence par « `%` » suivi par « `PS-Adobe` », il s’agit d’un fichier Postscript. Il semble qu’OpenOffice ajoutait la date au fichier et donc, le mardi cela prenait cette forme « `% Datedecréation:` » soit `TUE MMM D hh: mm:…`



Une erreur dans l’écriture du motif pour reconnaître les fichiers Erlang JAM faisait que « Tue » dans le fichier Postscript était, du coup, reconnu comme un fichier Erlang JAM et, de fait, pas envoyé à l’impression.



Le modèle de fichier Erlang JAM était le suivant :



````4 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file – version 4.2````



Alors qu’il aurait dû être :



````4 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file – version 4.2````



Autrement dit, tous les fichiers commençant par les caractères « Tue » étaient reconnus comme étant de type `Jan 22 14:32:44 MET 1991 Erlang JAM file – version 4.2`. Alors que le comportement attendu est que tous les fichiers commençant par `Tue Jan 22 14:32:44 MET 1991` soient reconnus comme étant de type `Erlang JAM file – version 4.2`.



- [Version originale](http://beza1e1.tuxen.de/lore/print_on_tuesday.html)
- [Rapport du bug](https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619)



Le Raspberry Pi qui redémarre quand on le prend en photo
========================================================



Un utilisateur du Raspberry Pi avait remarqué que l’ordinateur plantait lorsqu’il le prenait en photo. Phénomène qui semble difficile à expliquer a priori. Les ordinateurs ne sont normalement pas timides à ce point ?



L’explication est liée à la présence dans le circuit d’alimentation du Raspberry Pi 2 d’un composant sensible à la lumière. Un flash d’appareil photo ou un pointeur laser peuvent donc provoquer des perturbations sur l’alimentation électrique, faisant planter ou redémarrer le système.



Il s’agit d’un composant sans package (plastique ou céramique), ou le substrat de silicium est exposé à l’air libre. Ce type de composant est habituellement utilisé dans des smartphones, où il n’y a pas de place à perdre avec un tel emballage, et où la coque du smartphone offre une protection suffisante. Mais ce n’est pas le cas sur le Raspberry Pi, qui est vendu sans boîtier.



- [Version originale.](https://hackaday.com/2015/02/08/photonic-reset-of-the-raspberry-pi-2/)



Le serveur mail qui refuse d’envoyer les mails plus loin que 500 miles (environ 805 km)
===========


L’administrateur système d’une université reçut un jour ce rapport de bug surprenant venant du département de statistiques de ladite université : « depuis quelques semaines, nous n’arrivons plus à envoyer des courriels à des destinataires distants de plus de 805 km ».



Réaction initiale : « impossible, le courriel ne fonctionne pas comme ça ». Pourtant, les données sont claires (on parle du département de statistiques, qui a pris le temps de collecter les données et de les analyser pour identifier le motif entre les échecs et réussites d’envois de courriel). Quelques essais avec différents serveurs situés plus ou moins loin confirment ce comportement.



Après analyse, lors d’une mise à jour du serveur de courriel, le démon d’envoi de messages a été remplacé par une version plus ancienne et un fichier de configuration n’a pas été adapté en conséquence. Un _timeout_ pour l’ouverture de connexions TCP était laissé non configuré, et la valeur par défaut dans le logiciel était de 0. Résultat : l’ouverture de connexions n’était possible que si la réponse arrivait très rapidement entre l’exécution de deux lignes de code. Un calcul rapide mettant en rapport la vitesse du processeur du serveur et la vitesse de la lumière dans les fibres optiques permit de confirmer que cela donnait une limite d’environ 805 km.


- [Version originale.](https://www.ibiblio.org/harris/500milemail.html)



# Un chat assis sur le clavier fait planter LightDM



La description du [premier bug](https://bugs.launchpad.net/unity/+bug/1463112) est la suivante :



> Ubuntu 14.04, écran verrouillé je pars déjeuner, au retour de mon déjeuner mon chat était assis sur le clavier, l’écran de connexion était bloqué et ne répondait pas
>
> Pour reproduire : dans Unity, appuyer sur ctrl-alt-l, mettre le clavier sur la chaise. S’assoir sur le clavier.



Une autre réponse :



> Bizarrement, j’ai eu aussi le même problème la nuit dernière. Aussi causé par un chat.



Description d’[un autre rapport bug](https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1538615), ouvert six mois plus tard :



> Étapes pour reproduire :
>
> 1. laisse l’ordinateur sans surveillance dans une salle froide avec un chat chaud ;
> 2. le chat va s’assoir sur le clavier de l’ordinateur ;
> 3. attendre une heure ;
> 4. Lightdm va se bloquer.



Finalement, le problème était, tout simplement, dû au fait que cela remplissait le champ de mot de passe de tellement de caractères que le système devenait terriblement lent (peut-être le rendu des puces dans le champ de texte ?) et bloquait presque tout le reste… Le champ a finalement été limité à 200 caractères.



# La voiture allergique à la glace à la vanille



Où le nouveau propriétaire d’une Pontiac constate que sa voiture ne démarre pas quand il achète de la glace à la vanille le soir et seulement quand il s’agit de glace à ce parfum[^1]. La deuxième plainte de l’automobiliste finit par décider la firme à envoyer un ingénieur pour constater de la réalité des faits. Lequel, mène l’enquête, compile les données de toute nature (durée du trajet, heure, type de carburant, etc.) et fait la même constatation après l’achat de glace à la vanille dans le même magasin pour le même modèle de voiture.



Allons bon ! Comment une voiture pouvait être allergique à un parfum de glace. En fait, il se trouve que dans le magasin en question, ce parfum de glace étant le plus vendu, on se le procurait à un comptoir dédié, plus près de la sortie et que la voiture n’avait pas eu assez de temps pour refroidir : il y avait un blocage dû à la vapeur qui n’avait pas eu le temps de se dissiper et qui empêchait la voiture de démarrer.


[Version originale.](http://beza1e1.tuxen.de/lore/allergic_car.html)



[^1]: Et où cette histoire semble assez peu crédible pour des critères européens. Mais elle reste, tout de même instructive.

You are viewing proxied material from bitreich.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.