La voiture allergique à la glace à la vanille, et autres bugs

65
5
juin
2021
Humour

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, 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).

Sommaire

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.

Une histoire étrangement similaire est racontée, près de 20 ans plus tôt, dans la lettre de BeOS, 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 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.

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.

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.

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.

Un chat assis sur le clavier fait planter LightDM

La description du premier bug 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, 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 parfum1. 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 vaporisation du carburant dans le circuit d’alimentation, ce qui empêchait la voiture de démarrer.

Version originale.


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

Aller plus loin

  • # Attaques hardware

    Posté par  (site Web personnel) . Évalué à 10 (+34/-1).

    Pour l'exemple du Rapsberry Pi, c'est quelque chose qu'on connait bien dans l'industrie de la carte à puce, qu'on appelle simplement les attaques "flash". C'est utilisé depuis des années. L'intérêt est que pendant le flash et pendant quelque micro-secondes après, le processeur effectue des NOP au lieu d'instructions valides, mais il incrémente quand même le compteur d'instruction. Ca permet donc de sauter quelques instructions assembleur.

    L'attaque est très peu coûteuse en matériel, il faut un appareil photo en gros, gratter un peu la puce pour que la lumière pénètre et un bon système de synchronisation pour déclencher le flash au bon moment.

    Il suffit de déclencher à la fin du IF qui vérifie que ton code PIN est faux et se termine par un return pour arriver dans le ELSE où ton code PIN est censé être juste. C'est déclinable selon plein de variantes et les labos de tests de sécurité s'amusent beaucoup avec ça. Inutile de préciser que c'est dévastateur en terme de cassage de cartes/algo/sécurité.

    Pas cher en matériel et dévastateur en sécurité, autant dire qu'on a pas intérêt à laisser passer de près ou de loin ce genre de truc.

    Du coup, on déploie plein de contre-mesures, qui vérifient qu'on est bien arrivé dans un bout de code pour une bonne raison. Ces contre-mesures n'ayant aucune validité si on analyse le flot de code logique, elles se font parfois virer lors de la compilation ou à l'édition de lien des compilos performants. Ou bien ça marche une fois et la version mineure suivante du compilo va elle virer la contre-mesure. Donc on s'amuse à auditer une partie du code assembleur pour vérifier que le compilo a pas tout sagouiner notre code. Bref, on s'amuse bien par chez nous.

    L'un dans l'autre, on se prend dans les 10% de code en plus rien que pour cette attaque. Et les labos de tests un peu sournois commencent à nous balancer des doubles ou triples attaques flash, où ils vont nous nicker le code principal dans un premier temps, puis la contre-mesure. Là, ça peut vraiment faire mal et être pénible à protéger.

    • [^] # Re: Attaques hardware

      Posté par  . Évalué à 4 (+1/-0).

      J'ai du mal à suivre. Autour de 2008, on avait acheter un LSM pour faire exactement ça. Des attaque ciblé pour ajouter un '1' a un endroit de la puce. Le truc était d'éviter des détecteurs qui bloquait la puce.

      Tu semble dire que le flash qui arrose la puce, ne semble pas activer ce genre de protection hardware ?

      "La première sécurité est la liberté"

    • [^] # Re: Attaques hardware

      Posté par  . Évalué à 2 (+1/-1).

      C'est intéressant, mais ça me fait me poser une question.

      Je suis très mauvais en correspondance code/assembleur, il ne faut pas voir mon commentaire comme une explication de comment faire, mais comme une discussion.

      Les langages qui remplacent les if/then/else par des types fantôme + du polymorphisme ne sont pas moins sensibles à ces problèmes ?

      À ce moment là ton compilateur peut prouver que tu es où tu es pour de bonnes raisons, mais peut être que cette caractéristique n'est pas garantie dans le binaire généré ? Outre le fait qu'il n'existe peut être pas de langage permettant cela et pouvant cibler une carte à puce…

      • [^] # Re: Attaques hardware

        Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

        Tu as un peu pressenti la réponse: on utilise que trois langages dans la carte à puce. Le C, l'assembleur et le javacard. On pourrait dire quatre langages puisqu'une boite à succès utiliser une machine virtuelle avec du Forth et a sorti pas mal d'applications certifiées avec (sauf que c'était limite plus pénible à programmer que de l'assembleur à la main).

        En tout cas, très clairement, un langage trop éloigné de l'assembleur qui réorganise le code en fonction des informations qu'il a pourrait poser problème. Cela dit, si on passait à un langage plus haut niveau, j'espère qu'on pourrait intégrer la notion de sécurité par une approche haut-niveau dans le code, genre un sorte de "secured if" sous forme de fonction.

        Dans le cas de Javacard, on peut intégrer des sécurités dans cet esprit au niveau de la VM Java, ce qui est parfois pratique.

        • [^] # Re: Attaques hardware

          Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

          J'avais un jour assisté à une conférence sur ces questions de sureté de code. Dans un environnement "hostile" (je ne sais plus trop le contexte : nucléaire, ou ce genre de truc), une solution avait été de compiler le programme deux fois, avec deux compilateurs différents. Les deux programmes s'exécutaient en parallèle, et des points de contrôles avaient été mis en place dans lesquel chaque programme attendait que l'autre produise le même résultat avant d'embrayer sur la suite.

          Comme le source était le même, il était attendu que le résultat soit identique, mais l'utilisation de deux compilateurs faisaient qu'un incident survenant sur l'exécution d'un programme n'avait pas le même impact sur l'autre, ce qui protégeait la solution.

          • [^] # Re: Attaques hardware

            Posté par  . Évalué à 3 (+2/-0).

            des points de contrôles avaient été mis en place dans lesquel chaque programme attendait que l'autre produise le même résultat avant d'embrayer sur la suite.

            Et il se passait quoi si l'autre n'avait pas le même résultat (ou plantait par exemple) ?

            • [^] # Re: Attaques hardware

              Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

              Les deux process étaient relancés à partir du point de contrôle précédent tout simplement. Il faut garder à l'esprit que dans ce contexte, c'était la sureté de l'exécution qui était mise en avant, au détriment de la vitesse, et cela a à la fois des impacts sur le fil d'exécution du programme, mais sur le hardware mis en place autour.

              De mémoire, il y avait peut-être un contrôleur d'exécution, qui s'assure que les deux programmes s'exécutent correctement, qui se trouvait dans une "chambre forte" protégée de tout environnement (radiation, ionisation etc). Au final cela revenait moins cher de mettre seulement ce dernier élément en confinement, et laisser les processeurs/microcontroleurs subir les attaques de l'environnement plutôt que créer une brique complète qui protège l'ensemble du système. (je ne sais plus trop si les programmes s'autocontrôlaient ou si cela était fait en extérieur — l'idée étant là, on peut imaginer les deux)

          • [^] # Re: Attaques hardware

            Posté par  . Évalué à 4 (+1/-0).

            Il doit etre possible de faire 2x les operations par le compilo qui vérifie lui même le resultat et recommence en cas de différence.

            Cela serait utile en carte a puce et dans le spatial.

            "La première sécurité est la liberté"

            • [^] # Re: Attaques hardware

              Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

              Ça se fait effectivement pour la sécurité, y'a des travaux autour de ça au CEA par exemple.

              Pour la sûreté dans le spatial, je ne crois pas qu'on arrive à se passer de redondance matérielle : les fautes matérielles liées au rayonnement ont tendance à se propager et à faire sauter plusieurs choses d'un coup. Mais l'étude des interactions entre les mécanismes de tolérance aux pannes hard et le soft est un sujet de recherche intéressant et actif par contre.

              • [^] # Re: Attaques hardware

                Posté par  . Évalué à 4 (+1/-0).

                Les protections hard dans le spatial, c'est juste de la triplication des registres. Ainsi, en cas d'erreur entre 2 registres, c'est corrigé. Je n'ai jamais entendu parler de puce de carte à puce fait ainsi.

                Ce genre de hard spécifique est couteux. Un compilo spécial serait réutilisable. En fait, l'idéal est la triplication. Il faut tripliquer les mémoires, les exécutions, et sans doute le code objet aussi. Entre 2 calculs, il faut vérifier les 3 résultats, si l'un est différent, il faut y recopier la valeur des 2 autres. Il faut un traitement spécial des IOs, par contre, pour ne pas faire 3 printf identiques de suite.

                Je n'en jamais entendu parlé de ce genre de truc. Pourtant, cela serai utile dans pas mal de cas.

                "La première sécurité est la liberté"

        • [^] # Re: Attaques hardware

          Posté par  . Évalué à 3 (+1/-0).

          Cela dit, si on passait à un langage plus haut niveau, j'espère qu'on pourrait intégrer la notion de sécurité par une approche haut-niveau dans le code, genre un sorte de "secured if" sous forme de fonction.

          C'est ce à quoi je pensais avec les phantoms types. Très très grosso modo au lieu d'avoir un if, le code qui doit être exécuté en cas de sucés est une fonction dont l'argument n'est pas une string, mais un "pin valid" (c'est son type) et la seule manière d'obtenir une variable de ce type c'est de passer par la fonction qui vérifie le pin. Il me semble que ça peut protéger plus naturellement des problèmes dont tu parle, mais

          • si les compilateurs ne pensent pas à ce problème peut être qu'ils ne vont pas propager cette garantie dans le code généré, comme ils sont en mesure de vérifier statiquement tout ça en principe ils pourraient bien faire ce qu'ils veulent
          • s'ils le font mais pas tout le temps, tu ne peux pas (ou difficilement) reprendre la main sur le code généré pour corriger le problème (avoir un bout de code C ou assembleur)

          C'est dommage je suis sûr qu'un compilateur pourrait implémenter cette sécurité :(

  • # lien brisé

    Posté par  (site Web personnel) . Évalué à 5 (+2/-0).

    Pour « les vrais programmeurs », il y a deux urls sous Version originale.

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: lien brisé

      Posté par  . Évalué à 3 (+1/-0).

      Corrigé, merci.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Abba

    Posté par  . Évalué à 8 (+7/-0). Dernière modification le 06/06/21 à 10:17.

    L'histoire du mail qui ne dépasse pas une certaine distance est géniale.

    J'aime beaucoup aussi l'histoire de l’œuf de Pâques dans la commande man qui fait (faisait) planter des tests d'intégration continue entre minuit et 1h du matin, pour le plaisir de faire une blague liée à une chanson de Abba.

    • [^] # Re: Abba

      Posté par  . Évalué à 2 (+1/-0).

      Plutôt qu'une blague je le vois comme une fonctionnalité cachée ;-D

  • # Gimme gimme gimme! (a man after midnight)

    Posté par  . Évalué à 9 (+8/-0).

    Des tests nocturnes qui parsaient en autre le manpath obtenu avec man -w, échouaient toutes les nuits. En effet, près minuit la commande man sans nom de page écrivait « Gimme gimme gimme! » sur stderr, un Easter egg en référence à la chanson d'Abba, retiré depuis. Source en anglais.

    Cette signature est publiée sous licence WTFPL

  • # mot manquant

    Posté par  . Évalué à 3 (+2/-1).

    et quand une était finie

    instruction ?

  • # Cela me rappelle un bug ...

    Posté par  . Évalué à 10 (+25/-0).

    Cela me rappelle un bug qui m'a pris la tête pendant au moins une semaine. Mon histoire n'est pas aussi intéressante car au final il ne s'agissait que d'un banal dépassement de tableau.
    Je développais un compilateur et un jour je constate plusieurs plantages sur un serveur de tests. Des joli segfaults bien propres. J'essaye sur ma machine et surprise … cela fonctionne. Idem sur les autres serveurs à ma disposition. Le bug ne se produit que sur 1 seul serveur. C'est inhabituel car cet outil est sensé être parfaitement déterministe.

    Pour ne rien arranger, le bug disparaît quand je recompile en mode debug et Valgrind ne me dit rien d'intéressant. Les serveurs sont identiques avec les même processeurs, les mêmes DRAMs, le même OS (debian) et les mêmes bibliothèques. Je m'assure que la randomization d'adresses est désactivée, que tout les fichiers concernés (data, libs, exécutable, …) ont les mêmes checksums, que les horloges sont bien synchronisées, que le kernel linux est identique, … etc etc etc
    Tout est pareil mais ce fichu test continue à planter sur un unique serveur. C'est la 5ieme dimension ce truc. Est ce que le bug serait dans le hardware? C'est rare mais cela m'est déjà arrivé. Après plusieurs jours, je commence à sérieusement douter de mes capacités. Peut être ne saurais je jamais pourquoi notre compilateur plante sur zorglub-test mais pas sur paglop-test ou iznogoud-test?
    WTF … wait a second … "zorglub-test" fait 12 caractères de long alors que les 2 autres en font respectivement 11 et 13. Cela ne peut pas être aussi simple:

    # ./run-buggy-test
    segfault
    # export HOSTNAME=123456-test
    # ./run-buggy-test
     => Success

    Et si! Le système de logs du compilateur initialisait une chaîne de caractères contenant le HOSTNAME dans un tableau trop petit de 1 caractère. Classique! Moins de 12 caractères, pas de problèmes. Plus de 12 caractères, dépassement de tableau mais pas de crash. Exactement 12 caractères et le \0 de fin passe la variable immédiatement après le tableau de vrai (1) à faux (0) et beaucoup plus tard … BOOM.

  • # "blocage dû à la vapeur"

    Posté par  . Évalué à 6 (+5/-0).

    J'ai eu bien du mal à comprendre alors si cela peut aider d'autres lecteurs dans ce cas : "vapor lock" (en v.o.) fait référence à la vaporisation du carburant dans le circuit d'alimentation du moteur, cause des soucis au redémarrage.

    • [^] # Re: "blocage dû à la vapeur"

      Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

      Donc si je remplaçais le blocage par "vaporisation du carburant" ça le fait ? Laquelle vaporisation si je comprends bien fait que le carburant n'arrivait pas sous une forme utilisable au moteur.

      Designeuse de masques pour sphéniscidés.

      • [^] # Re: "blocage dû à la vapeur"

        Posté par  . Évalué à 5 (+4/-0).

        Dans le moteur, l'état utilisable du carburant c'est liquide, tu as bien compris ;-). Voici donc une proposition de reformulation : "il y avait vaporisation du carburant dans le circuit d'alimentation, ce qui empêchait la voiture de démarrer." Cela me semble plus clair, même si je n'y connais pas grand chose.

        • [^] # Re: "blocage dû à la vapeur"

          Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

          Vendu :-) ! Et corrigé, merci, c'est mieux comme ça.

          Designeuse de masques pour sphéniscidés.

        • [^] # Re: "blocage dû à la vapeur"

          Posté par  (site Web personnel) . Évalué à 3 (+1/-0). Dernière modification le 07/06/21 à 06:26.

          Ne serait-ce pas plutôt dans le circuit d’alimentation que l’état du carburant doit être impérativement liquide ? Dans le cylindre, s’il est sous forme de vapeur, cela ne ferait qu’améliorer la combustion. Dans les conduites en revanche, à même débit volumique, cela réduirait drastiquement le débit molaire…

          « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # Salle de réunion avec application web manquante

    Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

    Il m’est déjà arrivé une histoire du même niveau : Une salle de réunion dans la quelle une web application interne ne fonctionne pas.

    Un utilisateur me contacte pour un problème d’accès sur cette application interne depuis une salle de réunion. Le contact se fait par la messagerie d’entreprise, depuis la salle de réunion, donc il as du réseau.
    Un panel d’autres applications fonctionnent.

    Je me déplace, j’essaye … fonctionne pas …
    Mais le tout fonctionne dans plusieurs autres salles du bâtiment.

    Comment peux on perdre UN site intranet dans UNE salle de réunion ?

    Après un ensemble de test et de vérification nous avons trouvé le coupable : Mauvais VLan configuré sur les prises réseau de la salle de réunion.
    Ce dernier filtrant la zone spécifiques aux serveurs de l’application incriminé.

    Pour moi qui ai, à priori, dit à l’utilisateur «Mais c’est pas possible que tu n’ai pas accès qu’à UNE application web», c’était finalement vrai.

  • # Une autre histoire

    Posté par  (site Web personnel) . Évalué à 10 (+10/-0).

    Je viens de lire l'histoire de l'imprimante qui ne fonctionne que quand la porte de da pièce est ouverte:

    https://twitter.com/ASeemueller/status/1351137587960930304?s=20

  • # Mon histoire perso: failli mourir à cause d'un DRM

    Posté par  (site Web personnel) . Évalué à 10 (+10/-0). Dernière modification le 07/06/21 à 10:00.

    Adolescent, j'aimais beaucoup un jeu qui s'appelait The Nomad Soul. Le jeu bénéficiait d'une bande son écrite par David Bowie, bande son qui devait être protégée par un DRM. Quand je jouais, j'avais remarqué que le lecteur CD, un lecteur où l'on insère le CD (slut-in) s'emportait et se mettait à tourner très vite. Un jour, alors que je jouais, j'entends le lecteur CD qui s'emballe, tourne de plus en plus vite, et d'un coup: "Scratch, boum.", le CD explose dans le lecteur, des morceaux (de CD, pas de musique) fusent dans tous les sens. Un notamment se plante littéralement dans mon siège en cuir, à la hauteur de mon cou.

    Le lecteur était évidemment mort, le jeu plus utilisable car il manquait un CD et j'avais eu une belle frayeur. Après avoir consulté les forums sur Internet à l'époque, j'avais vu que d'autres personnes avaient eu le même problème notamment avec des lecteurs slut-in et qu'une action s'organisait aux États-Unis. Ce problème semblait lié au DRM, car il requerrait une lecture rapide du CD.

    J'ai essayé de retrouver des traces sur Internet des discussions liées à ce problème aujourd'hui, mais les messages semblent avoir été emportés dans les limbes d'Internet.

  • # Le plantage horaire

    Posté par  . Évalué à 7 (+5/-0). Dernière modification le 07/06/21 à 10:29.

    Dans le genre "plantage à certaines heures et pas à d'autres", je vous propose le problème suivant :

    J'ai un outil qui permet de lancer et/ou planifier le lancement de tests sur un banc de test (de satellite, mais peut importe) La façon la plus classique de l'utiliser, c'est de l'ouvrir, choisir mon test, et de le lancer. Je peux aussi choisir de le lancer plus tard, mais par défaut, il est mis dans la file de test à l'heure du lancement. Il y a donc un champ "heure" et un champ "minute" (pas de secondes) qui afficherait 10 et 20 respectivement si je lançais le test à cette heure ci (il est 10h20 quand j'écris)

    L'outil se charge ensuite de lancer le test à l'heure dite (donc tout de suite, si le banc est dispo et qu'il n'y a pas de test en cours, sinon il s'arrange pour le mettre en file d'attente, on a la possibilité d'ajouter des priorités, etc)

    Le problème : Parfois, ça ne marche pas.

    Je vais maintenant vous donner les premiers éléments que l'on a rassemblés, puis je vous donnerai dans la partie 2 des éléments plus précis, mais que je n'avais pas avant de comprendre le bug, donc si vous aimez le défi, ne lisez pas la partie 2.

    Partie 1 :

    Pendant la journée, ça marche la plupart du temps, mais une fois de temps en temps, ça ne marche pas. Sauf le matin, où quand j'utilise l'outil relativement tôt dans ma journée, ça plante régulièrement. Je n'arrive pas forcément très tôt au boulot (disons entre 8h30 et 9h), mais je lance rarement un test dès que j'arrive, ça prend un peu de temps. (généralement je préfère finir le test le jour avant et le lancer la nuit, comme ça je n'ai pas besoin d'attendre le temps du test/la disponibilité du banc)

    Quand je demande à décaler le test, ça marche à chaque coup, même si je ne décale que d'une minute. Donc quand je rentre l'heure à la main, ça marche.

    Partie 2 :

    • La fréquence des plantages pendant la journée est de un plantage sur 30 exécutions, en moyenne.

    • Les test qui plantent le matin, sont ceux qui sont lancés avant 10h. Sauf pour un collègue qui arrive tôt au boulot, qui lui me dit que quand il lance un test très tôt, ça ne plante pas. Il arrive vers 7h au boulot.

    J'écoute vos suggestions, quelqu'un a-t-il une idée ? (ce n'est pas pour vous faire bosser à notre place, le bug est résolu depuis plus de 10 ans)

    Heureusement le satellite en lui même est plus robuste que le banc…

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Le plantage horaire

      Posté par  (site Web personnel) . Évalué à 4 (+3/-1).

      Je pense que je vois le problème mais je ne veux pas donner la réponse tout de suite pour laisser les autres lecteurs chercher un peu :)

    • [^] # Re: Le plantage horaire

      Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

      J'essaie de trouve des indices de cause dans ce que tu écris.

      Voyons, est-ce que lié à des décalages horaires ?

      Designeuse de masques pour sphéniscidés.

      • [^] # Re: Le plantage horaire

        Posté par  . Évalué à 5 (+3/-0).

        Non, pas de décalage horaires.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Le plantage horaire

        Posté par  . Évalué à 2 (+1/-0).

        Par décalage horaire, j'imagine qu'il faut comprendre la synchronisation des horloges (NTP). Une mauvaise synchro, peut causer des problème bizarre par exemple avec les systèmes de fichier en réseau. Par exemple, Make peut se mettre à ignorer certains fichiers récents car ils ont une date dans le futur.

    • [^] # Re: Le plantage horaire

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

      Histoire d'avoir des informations supplémentaires, que tu avais forcément mais que nous n'avons pas puisque nous n'avons pas le contexte général :
      - combien de temps dure un test en moyenne ?
      - combien étiez-vous à utiliser le banc de test ?

      • [^] # Re: Le plantage horaire

        Posté par  . Évalué à 4 (+2/-0).

        Un test dure entre moins d'une minute et plusieurs heures, et on était plusieurs (moins d'une dizaine) à utiliser le banc. Mais en fait ça n'a pas d'influence sur le bug ;-)

        Lle problème arrivait au moment de l'insertion du test dans la file d'attente, donc pas au lancement, et ce n'était pas un problème d'insertion concurrent par plusieurs personnes.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Le plantage horaire

      Posté par  (site Web personnel) . Évalué à 10 (+9/-0).

      Sinon, si l'heure est rentrée de manière automatique avec un 0 devant, mais que vous ne le faite pas manuellement, c'est peut être un problème de conversion de octal/décimal.

      07 existe en octal, pas 08 ni 09. Mais 10 et 11 oui.
      Après pour les tests l'après midi, cela dépendrais du moment où le test est lancé (si c'est à 08 ou 09 minutes) ça peut planter, et cela correspondrait au ratio des plantages de l'après-midi (1/30).

      J'ai eu le cas avec une saisie de date ! L'application marchait nickel, sauf pour certains où parfois, la saisie d'une date de naissance ne fonctionnait pas. Bien sur, en prenant le même navigateur, cela marchait et impossible à reproduire.

      Après des jours de recherche, j'ai compris qu'ils utilisaient une très vieille version d'un navigateur (genre un firefox 16, merci la DSI !!!) et que la méthode javascript parseInt transformait un nombre commençant par 0 en base octale. En ECMA 5, c'est une base 10. Avant ECMA 5, c'était non spécifié (et donc certains navigateur prenait une base 10, et d'autres une base 8).

      • [^] # Re: Le plantage horaire

        Posté par  . Évalué à 9 (+7/-0).

        C'était ça. Effectivement, quand l'heure était rentrée automatiquement, elle était en deux chiffres (alors que si on rentre l'heure à la main, on rentrait "9" "42" par exemple, donc pas de 0 devant) Et derrière ce champ était interprété pour le transformer d'une chaine de caractère à un nombre, et ça plantait car 08 et 09 n'existent pas en octal, et tout le reste marchait comme attendu.

        Donc la journée, on avait une "chance" sur trente de tomber sur le bug, et le matin, entre 08:00 et 09:59 on tombait sur le bug à tous les coups. Et le collègue qui commençait plus tôt lançait ses test à 07:XX dont ça passait.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

        • [^] # Re: Le plantage horaire

          Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

          \o/

          Bon, après, comme dis plus haut, j'avais eu le souci dans un contexte un peu différent, mais même origine.

          Par contre, je n'étais pas aidé, car un seul utilisateur, dans un seul établissement rencontrait ce problème. Et bien sur, la personne n'étant pas du tout technique, cela n'aidait pas (genre, quelle version de Firefox utilisez vous ? Windows XP).

          Et comme elle était à 2h de route, que c'était la seule personne touchée (sur plus de 1000 utilisateurs), que le bug était plus ou moins intermittent, aucun déplacement pour aller voir sur place…

          Et c'est le genre de bug, qu'on passe 5s à résoudre une fois qu'on a trouvé l'origine du problème (qui elle par contre, peut prendre TREEEEEES longtemps à trouver)

        • [^] # Re: Le plantage horaire

          Posté par  . Évalué à 3 (+2/-0).

          Dans le même genre que l'octal il y a les problèmes liés aux locales. C'est bien connu pour les dates (1/4/21 = 1er avril en FR = 4 janvier en US) mais aussi pour les formats de nombres (19.5 en US = 19,5 en FR).

          (bash) export LC_ALL=C
          (bash) printf "%f\n" "4.5"
          4.5
          (bash) export LC_ALL=fr_FR.utf8 
          (bash) printf "%f\n" "4.5"
          bash: printf: 4.5: invalid number
          4,000000
  • # Mon père automaticien me raconte souvent un histoire du même genre...

    Posté par  . Évalué à 4 (+3/-0).

    C'était à une époque ou il bossait encore comme electro-mécanicien dans une société de production.

    Tous les jours vers 16h, il y avait une machine qui tombait en panne.
    Les conducteurs & manutentionnaires trouvaient çà sympa car c'est l'occasion d'une pose clope.

    Le plus bizarre ,c'est que genre 15min après la machine redémarré sans réel action corrective répétable.

    Mon père commençait se demander si les gars ne la mettaient pas en panne pour prendre une pose.

    Après quelques recherches, il comprit le problème. Vers 16h, un rayon de soleil venait éclairer un capteur optique qui se trouvait alors en défaut.

    • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

      Posté par  . Évalué à 10 (+11/-0).

      Ça me laisse dubitatif toutes ces histoires de rayon de soleil qui tape tous les jours à la même heure. Car l'inclinaison de la terre et sa rotation autour du soleil fait que tous les jours à la même heure, le soleil n'est pas orienté de la même façon. Il faut donc que ce soit une panne qui se décale tous les jours dans le temps. Il faut également qu'il fasse beau tous les jours, car si une lumière diffuse était suffisante pour causer le problème, il surviendrait à n'importe quel moment de la journée.
      Ou alors ce sont des pannes qui ont été résolues suffisamment rapidement, pour que l'on ne se rende pas compte du décalage temporel !?

      • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

        Posté par  . Évalué à 2 (+4/-3).

        Dans mon cas, je peux te certifier que c'est un cas réel vu que c'est mon père qu'il l'a traité ;-)

        Je lui demanderai combien de temps ce problème avait persisté.

        • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

          Posté par  . Évalué à 5 (+4/-0).

          Alors, je viens de l'appeler pour lui demander des précision.

          Plus exactement, c'était entre 11h et 12h et il ne se rappelle plus exactement combien de temps cela avait durée mais à priori longtemps. Il lui a fallu plus d'un an pour comprendre la panne. Cela ne le faisait pas tous les jours.

          C'était un genre de cellule infra-rouge sur une bascule.

          Et à priori, il a eu le même type de panne sur d'autres machines après.

          Donc je pense que cela ne doit pas être le seul electro-mécanicien /automaticien qui a rencontré ce type de panne :-).

      • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

        Posté par  . Évalué à 7 (+4/-0).

        Durant une saison donnée le soleil reste bas/rasant pendant une certaine durée. Et ensuite quand il s'agit de probleme thermique ça prend aussi un peu de temps. Mais c'est suffisant pour dire "autour de telle heure" même si on n'est pas à la minute près.

      • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

        Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

        C'est amusant, parce que moi, j'ai vu l'inverse.

        Durant la nuit en hiver, mais pas toutes les nuits, on recevait une alerte sur la bascule d'un lien réseau entre 2 bâtiments. La liaison entre le bâtiment principal et une maison un peu plus loin basculait sans raison sur le lien radio de secours. Et c'était toujours vers 4h/5h du matin. On a bien cherché du coté des updates, des opérations, etc, sans grand succès. On était pas motivé au point de rester debout à 4h du mat pour voir ça, mais bon.

        Ça a duré quelque semaines avant que finalement, quelqu'un se souvienne que si on avait mis un lien radio, c'était parce qu'on pouvais pas mettre de câble. Et donc que le lien primaire, c'était une liaison laser entre les 2 bâtiments qu'on avais mis en place avant, je suppose pendant l'été.

        Et en hiver, à 4/5h du mat, il y a parfois de la brume et ça marche un chouia moins bien à cause de la réfraction.

      • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

        Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

        Pour les deux qui sont listées dans la dépêche, au moins, la trame de l'histoire est vraiment trop proche (si on lit les versions originales en anglais). Mon avis est que quelqu'un a raconté la même histoire en la modernisant, en remplaçant le lecteur de disquettes par une XBox.

        D'où l'ajout du paragraphe sur les légendes urbaines en introduction (pas seulement pour cette raison, en fait: l'histoire de la glace à la vanille, a priori, c'est aussi du flan).

        Pour cette histore de rayon de soleil mal placé, j'ai cherché un peu, mais je n'ai pas trouvé de sources plus anciennes que la newsletter de BeOS. Celle-ci présente déjà l'histoire comme un "conte de fées" et ne prétend donc pas être très sérieuse. Mais j'avoue m'être souvenu de cette histoire comme si c'était réellement arrivé directement au responsable des tests de BeOS, avant de retrouver et de relire ce numéro de la newsletter et de me rendre compte que j'avais donc fait partie de la propagation de la légende urbaine.

        Finalement c'est peut être l'aspect le plus intéressant de ces histoires: mener l'enquête pour trouver d'où elles viennent, comment elles se propagent, et comment elles évoluent au cours du temps.

  • # Une autre histoire de chasse

    Posté par  (site Web personnel) . Évalué à 1 (+2/-3). Dernière modification le 07/06/21 à 14:26.

    C’est lié à l’informatique, mais ça n’en est pas.

    Dans une asso où j’étais bénévole, il y a un paquet d’années vu qu’il s’agit d’une connexion internet d’avant l’ADSL. L’ordinateur de l’asso n’arrivait pas à se connecter à internet. La bénévole informaticienne1 avait tout essayé (ou presque), rien n’y faisait. Cela durait depuis quelques semaines. Jusqu’à ce que j’aille au local.

    Ayant déjà changé plusieurs fois de FAI à l’époque, je savais me dépatouiller des configurations internet. Donc, puisque j’étais là, je me propose de jeter un coup d’œil au cas où. On me répond : « oui, mais ça ne sert à rien, Choséphine2 a regardé plus d’une fois et essayé des tas de trucs, ça ne marche pas, ça doit être l’ordinateur. »

    Okaydaccord, les réglages sont bons, l’ordinateur et le modem fonctionnent correctement. Et j’avise un tas de câbles3 qui traînent dans un coin. Je change le câble (il y en avait heureusement, ce qui est rare dans un tas de câbles qui traîne, un avec les bons connecteurs). Je relance, tout, l’ordinateur se connecte à internet sans renâcler.


    1. Après ça, ma cote, qui n’était déjà pas très bonne, est carrément tombée au plus bas de la fosse des Mariannes, je crois bien que je venais de commettre un crime de lèse-majesté informaticienne. 

    2. Le prénom a été changé, pour reprendre une formule consacrée. 

    3. Les tas de câbles qui traînent sont consubstantiels à l’informatique et se reproduisent naturellement, je ne vois que ça comme explication rationnelle à cet état de chose. 

    Designeuse de masques pour sphéniscidés.

  • # En Union soviétique, c'est la glace qui est allergique à la voiture

    Posté par  (site Web personnel) . Évalué à 9 (+7/-0).

    Je suis à peu près sûr d'être tombé sur cette histoire via Linuxfr, donc pardonnez mon repost, et par ailleurs il se peut que ce soit un récit apocryphe, mais il s'inscrit à merveille dans cette liste : "Le débogage derrière le rideau de fer". Je ne vous en dis pas davantage pour ne pas vous gâcher la chute.

  • # GitLab

    Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

    J'en ai eu un autre assez joli : un utilisateur n'arrive pas à se connecter à GitLab, erreur HTTP plus ou moins incompréhensible si on essaye de charger la page de login. Ça marche depuis un autre PC, mais même erreur quelle que soit le browser et la connexion internet.

    Problème résolu en remettant le PC à l'heure.

    L'explication est que le serveur envoyait un cookie avec date d'expiration très proche dans le futur, en se basant sur l'heure du serveur. Si le client avait une horloge mal réglée, le cookie arrivait avec une date d'expiration passée de point de vue du client, et paf.

  • # le pc qui ne supporte pas l'altitude

    Posté par  . Évalué à 4 (+1/-0).

    Au début de ma carrière quand je faisais du support desktop j'ai vu le cas d'un pc qui un matin n'a plus démarré chez une utilisatrice du dernier étage d'un bâtiment (je crois 8 ou 9ème?). Arrivé à mon bureau au sous-sol il fonctionnait. Je le remonte il ne fonctionne plus. J'inverse les câbles avec celui de la collègue, toujours le même pc qui ne démarre pas. Je le redescend il démarre sans broncher.

    Au final après l'avoir ouvert et nettoyé à l'air comprimé il a finalement pu reprendre service au dernier étage mais je n'ai jamais compris pourquoi si c'était un problème de contact avec une quelconque poussière il ne fonctionne pas seulement dans certains bureau, je ne pense pas que la différence de pression atmosphérique entre le 1er sous-sol et le 8-9ème étage soit une explication suffisante!

    • [^] # Re: le pc qui ne supporte pas l'altitude

      Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

      Neuf étages c'est pas l'Everest en effet.

      Designeuse de masques pour sphéniscidés.

    • [^] # Re: le pc qui ne supporte pas l'altitude

      Posté par  . Évalué à 3 (+1/-0).

      C'est pas la prise de courant qui déco-connait?

      • [^] # Re: le pc qui ne supporte pas l'altitude

        Posté par  . Évalué à 5 (+2/-0). Dernière modification le 08/06/21 à 10:16.

        Quand je dis que j'avais inversé le cablage du pc de la collègue je l'avais donc branché sur la même prise.

        Et au final le problème a quand même été résolu par le soufflage à air comprimé.

        • [^] # Plutôt la température

          Posté par  . Évalué à 4 (+2/-0).

          Dans les étages, il fait plus chaud qu’au sous‐sol.

          J’ai eu ce genre de problèmes. C’est difficile d’obtenir la réparation d’un PC garanti avec retour atelier quand il ne plante pas dans l’atelier (dans mon bureau au rez de chaussée non plus, mais si on ne peut pas l’utiliser au 3ᵉ, c’est quand même un souci).

          Bon, manifestement, pour celui dont tu parles, c’était un problème de poussière. Dans notre cas, c’était une série de cartes mères qui vieillissait mal.

          Frаnсе : 110344, Allеmаgnе : 89821. Масrоn : 20523.

          • [^] # Re: Plutôt la température

            Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

            Quand j'étais étudiant (ya bientôt 20 ans), un de mes collocs a dû pendant quelques mois « préchauffer » sa tour au seche-cheveux pour qu'elle daigne booter. Bon à la fin ça s'est fini par un remplacement de carte mère.

            Adhérer à l'April, ça vous tente ?

  • # Installation de Windows qui plante toujours au même moment

    Posté par  . Évalué à 7 (+6/-1).

    Durant l'été 2001 je devais installer MS-Windows (95 je suppose) sur un PC pour mon travail. Rien de bien palpitant à première vue mais: le logiciel d'installation démarre du CD, pose les questions habituelles puis finalement commence la partie lourde: reconnaissance du matériel, configuration des drivers et copie de fichiers (tiercé non gagnant :-) ). Dans moins d'une heure je pourrais commencer à travailler… mais au beau milieu de la procédure, la machine plante et s'arrête. Comme il s'agit d'un PC assemblé avec des pièces de provenance pas forcément très noble, je penche sur un problème de compatibilité entre le logiciel et le matériel. Je fais un reset du BIOS et recommence… au bout d'une belle demi-heure sensiblement au même point la machine s'arrête. Dans la journée je multiplie les tentatives infructueuses, puis finalement prépare un support d'installation Debian avec un autre ordinateur pour lancer l'install… qui va elle aussi planter. Le lendemain je décide d'ouvrir la machine et de retirer tout ce qui n'est pas nécessaire (lecteur de disquettes) ou de retirer-remonter ce qui l'est (RAM) … et découvre un amas effrayant de poussière coincé dans le CPU qui l'empêchait carrément de tourner! Pour se protéger de la surchauffe le CPU s'éteignait (ou plantait, je ne sais pas trop) le temps dont il avait besoin pour arriver à cet état faisait planter mon installation presque toujours au même moment… mais n'avait rien à voir avec ce que faisait réellement la machine! :-)

  • # Les claviers qui bloquent tout

    Posté par  (site Web personnel) . Évalué à 10 (+8/-0).

    Deux histoires différentes, mais avec un dénominateur commun : un clavier !

    La première : j'achète un duo clavier/souris sans fil. Tout se passe bien, je branche sur le PC, tout fonctionne nickel. Le lendemain, lorsque j'essaie de me servir de l'ordinateur : impossible de le démarrer. J'ai un petit message "No bootable disk". Comme j'ai toujours un live CD qui traine, je regarde et pars à la recherche d'un disque qui commencerait à rendre l'âme. Pourtant, rien. J'ai quand même réparé grub au cas où. Je reboot, toujours "No bootable disk". Je commence à perdre patience, surtout que je n'ai rien fait qui pouvait expliquer ça si subitement, et que la seule piste valable s'est retrouvée être infructueuse. J'ai même fini par démonter le disque dur pour le mettre dans une autre tour, et aucun soucis de démarrage.

    Je repasse donc dans ma tête ce que j'ai pu faire, et je me souviens du clavier que j'avais changé la veille. C'est tellement anodin que je me dis non, ça ne peut pas être ça. J'essai malgré tout et je débranche le clavier. L'ordinateur démarre normalement. Je rebranche le clavier, il fonctionne correctement. Je redémarre la machine : elle ne boot pas. Problème trouvé ! Mon clavier était vu par le BIOS comme un dispositif de stockage !

    La seconde : cette fois-ci, ça touche Windows (oui, c'est un appel au troll xD). Pas de soucis majeur avec Windows 10 depuis que j'ai ma bécanne (2017). Et là, 2020, une mise à jour qui ne s'installe pas. Une grosse mise à jour (genre la 20.04) qui plante en plein milieu avec le rollback qui va bien. Pas mal de recherche sur les forums, j'ai tout essayé, rien à faire, toujours le même plantage. J'avais pourtant pris soin de tout enlever, tous les périphériques inutiles, etc… Les logs m'indiquaient un driver non compatible mais sans préciser lequel. J'ai vu que VirtualBox pouvait causer ce genre de souci donc je l'avais supprimé, mais non, problème toujours présent. Et je n'étais même pas sur que ce soit ce souci de driver qui provoque le plantage. Bref, me souvenant de ma précédente histoire de clavier, je change le clavier par un bon vieux filaire. L'installation se déroule sans souci. Donc un clavier faisait planter la mise à jour de Windows. Et histoire de rajouter un argument un peu trolleste : le clavier qui faisait tout planter est un clavier Microsoft xD

  • # Un village perd la télé tout les matins à 7h pendant 18 mois

    Posté par  . Évalué à 6 (+5/-0). Dernière modification le 08/06/21 à 16:13.

    Cela se passait assez récemment dans un petit village du Pays de Gales.

    Tout les matins à 7h, les 400 habitants perdait temporairement leur signal TV.

    Au final, il s'est avéré que le problème venait d'un vieux poste que son propriétaire allumait probablement pour regarder les infos en prenant son petit déjeuner.

    https://www.bbc.com/news/uk-wales-54239180

  • # D'autres

    Posté par  (site Web personnel) . Évalué à 7 (+4/-0).

    Mais le plus improbable que j'ai connu reste : LinuxFr.org avec une horloge qui cyclait sur 4s.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.