Quel est le bug le plus récalcitrant que vous ayez rencontré ?

Citation:

---

Envoyé par screetch

Back on Wing Commander 1 we were getting an exception from our EMM386 memory manager when we exited the game. We'd clear the screen and a single line would print out, something like "EMM386 Memory manager error. Blah blah blah." We had to ship ASAP. So I hex edited the error in the memory manager itself to read "Thank you for playing Wing Commander."

---

Ou comment transformer un bug en feature... :aie:

Dans le même genre, je suis assez surpris du nombre de développeurs qui se servent des instructions "try...catch" comme s'il s'agissait de "if...else". Résultat, quand ça plante vraiment, personne ne s'en rend compte, sauf l'utilisateur final évidemment.

Sinon, de très gros bugs, j'en ai rarement eu. Ceux sur lesquels on s'arrache le plus les cheveux d'ailleurs sont souvent les plus basiques. La meilleure solution consiste à attendre une journée et à revenir dessus le lendemain. Enfin, les IDE de plus en plus performant empêchent maintenant ces petits tracas...

Lorsque j'ai publié mon précédent post sur ce fil, je n'osais pas encore parler de celui-ci : L'année dernière j'ai offert à ma famille un ordinateur Acer Revo.

Acheté avec Vista et le ticket de mise à jour vers Seven, j'ai installé Seven quand il est sorti en double-boot, et cela fonctionnait très bien. Mais il y a trois mois, par curiosité, j'ai voulu explorer les températures de fonctionnement du système avec Speedfan. Mon coeur n'a fait qu'un tour 73-74 °C... confirmé par le bios aussitôt sollicité pour en avoir le coeur net. Pourtant il ne présentait aucun défaut de fonctionnement particulier. Je désactive dans le bios la régulation "smart" du ventilo pour qu'il tourne au maximum en permanence.

L'appareil était encore sous-garantie pour quelques semaines. Je l'ai donc envoyé au SAV. Au bout de quinze jours environ l'appareil me revient, avec un changement de carte mère... et un Check sum error au démarrage.... Je modifie le Bios pour entrer la date et l'heure et je constate que je retrouve mes trois partitions et mes systèmes tels que je les avais envoyés. Température de fonctionnement un peu plus basse : 65° C. Mais après consultation du SAV, pour le check sum error systématique, retour au SAV... ils ont du oublier une pile.

Deuxième réception, encore changement de carte mère, ça démarre normalement, mais là je constate qu'on m'a réinstallé Vista et détruit mes partitions. Qu'à cela ne tienne je réinstalle l'ordi comme précédemment. Mais, au bout de quelques jours, plantage, écran bleu ou écran figé ou écran déformant l'image ou écran transformé en histogramme horizontal multicolor sur une partie de l'écran ou même parfois des barres verticales mauves sur fond gris ou des sifflements au redémarrage !!! je tâtonne et je rappelle le SAV. On accuse mon double boot. Je réinstalle l'ordi avec seulement Seven. je vérifie les Windows update et je contrôle systématiquement les dates de tous les drivers. Plantage à nouveau. On m'ouvre un nouveau ticket de retour.

Puis au cour d'ultimes manipulations avec beaucoup d'écrans bleus et variés, brusquement ils cessent... après avoir débranché et rebranché le cordon entre l'ordi et le bloc d'alimentation sur cette dernière. je me dis donc que ma prise était mal enfoncée et la température montant progressivement devait modifier le contact et créer des micros coupures.

Le lendemain, toujours pas de plantage, je rappelle le SAV pour annuler la demande de retour. Le technicien me fait remarquer que la garantie se termine le lendemain et que si j'annule, je ne pourrais plus avoir recours à la garantie. Je confirme mon annulation trop confiant... et le surlendemain à nouveau des écrans bleus et variés et voire des refus complets de démarrer, malgré les réparations proposées par Seven.

N'étant plus sous garantie, je démonte le capot. Je ne remarque rien d'anormal, mais je constate que l'ordinateur accepte de redémarrer à nouveau, mais ouvert. Je fais des tas de test. Bref je vous passe plusieurs épisodes de tâtonnement et de déceptions.

Finalement, dégoutté après avoir abandonné toute recherche de panne plusieurs jours de suite... l'ordinateur étant malgré tout utilisé avec des plantages fréquents au bout de dix à vingt minutes d'utilisation, mais refusant cette foi de démarrer définitivement, je rouvre et machinalement j'enlève les deux barrettes mémoire et je les interverti au remontage. Allez savoir pourquoi....

Et bien depuis plus aucun plantage.... Cela fait une semaine... juste une semaine.... après deux mois de "récalcitrance" ! En quoi intervertir deux mémoires identiques et d'origine peut-il jouer ? L'une d'elle était-elle mal enfichée ? J'avais pourtant effectué des test de mémoires qui ne signalaient rien.

sur ma machine en chargeant un jeu j'ai eu de temps en temps des "checksum error". Erreur un peu incompréhensible puisque les données sont compilées et recompilées, puis distribuées pour les autres machines. Pis des fois il y arrive, pis des fois il y arrive pas, ca dépend de l'humeur.
J'ai cherché dans le code de ZLib (qui faisait le checksum error) et j'ai même remis a jour ce code avec la version 1.2.je sais plus quoi. Toujours rien.

J'ai trouvé l'origine du problème plus tard lorsqu'en compilant le jeu, dans la bibliothèque Lua, le compilateur me disait brusquement : "redurn: identifier not found". Eeeeuh, oui, redurn, je regarde le code source, "redurn 0;", ca devrait etre un return. Je vérifie l'état du fichier sur notre dépôt, il dit bien return, il n'y a que sur mq mqchine que ca dit redurn.

Et bien en fait j'avais une barette de mémoire qui était un peu naze, qui avait un couple de bits (juste des bits!) toujours à 0 (la différence entre redurn et return est d'un bit). Alors des fois la mémoire touchée était au milieu d'un bloc zlib (d'ou l'erreur CRC) et d'autre fois c'était dans un bloc de texte qui était telechargé de notre dépot et enregistré sur le disque dur.
Du coup, on ne pouvait plus faire confiance a rien sur ma machine, a cause de 2 3 bits mal placés, il a fallu tout reinstaller (et virer les barettes mémoire au passage).

Citation:

---

Envoyé par screetch

Et bien en fait j'avais une barette de mémoire qui était un peu naze, qui avait un couple de bits (juste des bits!) toujours à 0 (la différence entre redurn et return est d'un bit). Alors des fois la mémoire touchée était au milieu d'un bloc zlib (d'ou l'erreur CRC) et d'autre fois c'était dans un bloc de texte qui était telechargé de notre dépot et enregistré sur le disque dur.
Du coup, on ne pouvait plus faire confiance a rien sur ma machine, a cause de 2 3 bits mal placés, il a fallu tout reinstaller (et virer les barettes mémoire au passage).

---

Ce qui expliquerait peut être mon problème. Mon win 7 32 bits n'utilise que 3 Go de mémoire sur les 4 Go... peut être que la partie "naze" de ma barrette est maintenant dans la zone inutilisée par Windows après mon interversion des barrettes ?

Citation:

---

Envoyé par ec

Ce qui expliquerait peut être mon problème. Mon win 7 32 bits n'utilise que 3 Go de mémoire sur les 4 Go... peut être que la partie "naze" de ma barrette est maintenant dans la zone inutilisée par Windows après mon interversion des barrettes ?

---

Non, c'est tout à fait normal. Les OS Windows 32 bits ne savent utiliser que 3,xxGO de Ram. Pour peu que tu ais une carte vidéo embarquée sur la carte mère et qui utilise aussi la mémoire centrale, ça te fera encore un peu moins pour le système.

Citation:

---

Envoyé par ec

Ce qui expliquerait peut être mon problème. Mon win 7 32 bits n'utilise que 3 Go de mémoire sur les 4 Go... peut être que la partie "naze" de ma barrette est maintenant dans la zone inutilisée par Windows après mon interversion des barrettes ?

---

Pas obligatoirement, le coups des barrettes de ram est un coups classique, chaque fois que mon PC ne damerait pas après un démontage complet suffisait d'intervertir la ram pour que sa marche, et moi je suis en x64 donc avec toute la mémoire utilisé !

Citation:

---

Envoyé par sevyc64

Non, c'est tout à fait normal. Les OS Windows 32 bits ne savent utiliser que 3,xxGO de Ram.

---

C'est précisément pour cela que j'ai fait cette réponse. Le fait que qu'il y ait un Go non géré par mon Windows prouverait que la cause de ma panne, avant inversion des barrettes, serait maintenant située dans ce Go non géré puisque je n'ai plus de panne.
Par contre Elepole me dit qu'il a eu aussi ce problème résolu de la même manière avec un Win 64. Alors....

C'est possible mais pas obligatoire. Ça arrive de résoudre des problèmes de mémoires en simplement intervertissant les barrettes (ou en les changeant de banques) sans pour autant que le problème vienne réellement des barrettes.
Ces barrettes pourraient fonctionner parfaitement dans n'importe quelle combinaison sur une autre carte mère. D'autres barrettes fonctionneraient aussi parfaitement sur cette carte mère.

Le bus mémoire est un bus avec un équilibre extrêmement précaire. Il peut arriver que des composants tant coté carte mère que coté mémoire, un peu juste tout en étant dans les normes de fonctionnement se révèle incompatibles s'il sont associés alors qu'ils ne le seraient pas, associés à d'autres.

J'ai déjà vu une carte mère avec 2 banques, sur une banque, je n'ai jamais eu de problème, l'autre banque n'arrivait à fonctionner qu'avec une certaine marque de chip mémoire. Une fois l'équilibre trouvé, la carte mère a fonctionner pendant plusieurs années sans aucun soucis.

Citation:

---

Quel est le bug le plus récalcitrant, improbable et non reproductible que vous ayez rencontré ?

---

Une reponse dans l'esprit du bug numero 1 de Ubuntu:
le bug le plus récalcitrant, improbable mais malheureusement fort reproductible : le liberalisme *o*
[humour iberique]

Citation:

---

Envoyé par vpourchet

petit rappel pour la culture, le premier 'bug' est apparu a l'age de pierre de l'informatique quand une seule machine prennait une piece entiere et qu les ordinateurs fonctionnaient avec des lampes, lors d'une operation une bestiole trop curieuse est rentree dans la machine provoquant un faux contact ...

c'etait la minute culturelle :mrgreen:

---

bug veut tout simplement dire insecte. :roll:

Oui, la légende dit que c'est lors de la recherche d'une panne en 1945 dans un des premier ordinateur électromécanique, le Harvard Mark II, que l'informaticienne Grace Hopper (amiral de la marine américaine) aurait trouvé un insecte de la famille des mites coincé entre les contacts d'un relais. Elle se serait alors écrié "It's a bug". L'expression serait partie de là.

Mais ce n'est qu'une légende, car le terme de bug désignant un dysfonctionnement était déjà utilisé par Thomas Edison dans ses notes personnelles datant des années 1870. Et l'était certainement bien avant lui, par d'autres.

L'origine du mot bug désignant un dysfonctionnement n'est pas bien connue, tout au moins incertaine, car les insectes causant des pannes ce n'est certainement pas nouveau.

J'ai souvenir de quelques bugs que j'ai eu à corriger sur une application il y a quelques années. Dans cette application se trouvait un calendrier entièrement codé en JavaScript dans lequel étaient affichés une série d'événements. Et deux champs de type Date (début et fin) permettaient de filtrer les données à afficher.

C'est en grande partie grâce à ce débogage que j'ai appris beaucoup de chose sur l'objet Date en JavaScript et à quel point celui-ci est vicieux.

Un des bug dont je me souviens : le client se plaignait qu'il y avait des événements qui disparaissaient de façon aléatoire dans le calendrier. Cela arrivait plutôt rarement mais c'était gênant pour les utilisateurs qui consultaient le planning chaque matin et pour qui un événement manquant pouvait leur faire rater une intervention, souvent importante.
D'autre part, le client en question était du genre à signaler des bugs qui n'existent pas. Il nous avait déjà fait le coup de nous signaler des anomalies qui étaient dues au fait qu'il ne lisait pas la procédure de mise en prod ou qu'il essayait d'ajouter lui-même de petites évolutions au code pour éviter de faire appel à nous et ainsi économiser quelques sous (il a d'ailleurs plus dépensé à cause de ça que ce qu'il a économisé, mais passons).

Pour revenir au bug, étant donné que l'on n'arrivait pas à le reproduire chez nous, on a rapidement conclu à une nouvelle lubie du client. Et c'est vraiment par hasard, plus tard, qu'il s'est produit sur mon poste : un événement avait disparu. Et en rafraichissant la page, l'événement est revenu et ensuite, j'avais beau rafraichir continuellement, aucune erreur ne se produisait. J'ai passé du temps avant qu'il ne se reproduise.

En fait, le code se présentait de la façon suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

var date1 = new Date(); date1.setYear(year); ...etc... date1.setSeconds(second); // DU CODE ICI var date2 = new Date(); date2.setYear(year); ...etc... date2.setSeconds(second); // DU CODE ICI if (date1 == date2) afficherEvenement();

---

En JavaScript, lorsque l'on utilise "New Date()", la variable est initialisée avec la date courante (millisecondes comprises). Et si, par hasard, le code ci-dessus s'exécutait à cheval sur 2 millisecondes, alors date1 et date2 devenaient différentes et l'événement ne s'affichait plus. De plus, les machines du client étant moins performantes que mon poste de dev, le code ci-dessus mettait plus de temps pour s'exécuter et la probabilité que l'erreur survienne s'en trouvait augmentée.

Sinon, sans rentrer dans le détail, il y a eu un autre bug dans ce calendrier qui se produisaient les 2 ou 3 premiers jour de chaque mois (le temps que le client nous le signale, celui-ci ne se produisait plus, et il a fallu un peu de temps pour comprendre qu'il ne se produisait qu'en début de mois) et un autre au passage à la nouvelle année. La plupart de ces problèmes étaient du au fait qu'il n'avait pas été pris en compte que l'objet Date en JavaScript s'initialisait à la date courante.

D'autre part, un autre piège vicieux sur l'objet Date en JavaScript, les mois sont comptés de 0 à 11 (alors que les jours sont bien de 1 à 31). C'est le genre de chose sur lequel on peut s'arracher les cheveux. Et un dernier piège en JavaScript auquel je me suis fait prendre, la conversion d'un String en Int avec "parseInt" se fait par défaut en base 8.

Sinon, j'ai d'autres anecdotes, mais je vais les raconter brièvement car je suis là en train d'écrire un pavé :
- Sur une appli qu'un de mes collègue venait de reprendre pour la faire évoluer, un ancien développeur avait ajouté une fonctionnalité qui modifiait tous les styles et qui affichait en gros un "Joyeux anniversaire" le jour de son anniversaire (tout redevenait normal le lendemain). Bien entendu, le développeur en question avait changé de boîte et de région entre temps et l'application était en prod dans le service RH d'une assez grosse société. Bref, le genre de blague qui peut faire rire, mais malheureusement pas tout le monde.
- Et enfin, il y a aussi le coup de l'application qui est très rapide lorsqu'on la livre au client et qui se met à ramer copieusement au bout d'un an d'utilisation. Simplement parce que pour l'affichage d'un tableau d'éléments, un des développeurs s'est passionné pour les requetes "SELECT". L'application récupérait d'abord l'intégralité des éléments puis pour chacun d'eux, elle faisait un "SELECT" supplémentaire (avec 15000 lignes dans la table, ça marche forcément beaucoup moins bien). Sans oublier de mentionner le fait que l'intégralité des éléments étaient requêtés alors que seulement quelques dizaines était affichée, la pagination était gérée à postériori. Rien de très complexe à corriger, mais un bel exemple de cas où les développeurs ne se préoccupent pas de la pérennité de leurs travail.

Merci aux courageux qui ont lu ce pavé :P

EDIT : Ce qui arrive à Apple et leur réveil sur Iphone en ce moment, c'est très similaire. Eux aussi ils l'ont fait en JavaScript ? :aie::aie:

Citation:

---

Envoyé par Barsy

Et un dernier piège en JavaScript auquel je me suis fait prendre, la conversion d'un String en Int avec "parseInt" se fait par défaut en base 8.

---

Ah le parseInt !!!!! Que de mauvais souvenir de bug à corriger.

C'est clair que si on a oublié que lorsqu'il neige il faut envoyer des agents sur le terrain avec des pelles et du sable, c'est a fortiori difficile de se rappeler où on a mis des câbles.
Et ce pays utilise l'énergie atomique.

Pour ma contribution, je vous propose non pas d'expliquer le détail technique du bug, mais tout le chemin parcouru pour arriver à le reproduire (le plus dûr), le comprendre et le corriger !

En gros, le problème visible commence par un watchdog de l'OS qui tombe (une tâche qui ne répond pas) et on arrive à un problème de sémaphore dans un boitier DpRam ... en passant par le debug à l'émulateur directement sur l'appareil cible (un gros onduleur qui fait bcq bcq de bruits). 1 mois pour arriver au bout quand même !

Un bon dessin vaut mieux qu'un long discours, voici une image des chemins parcourus pour arriver à lui tordre le coups. La structure et l'ampleur de la route est plus parlante que le contenu.
Je vous laisse jeter un oeil.

Ce fichier a été réaliser avec Freemind ... excellent soft par ailleurs. J'utilise souvent cette technique pour tracer les travaux de debug ... tracer toutes les pistes, les questions, les essais ... ne rien oublier !

J'ai rencontré un bug cette semaine en travaillant sur un projet scolaire en ruby.

Je devais concaténer 2 tableaux. Pour cela, j'ai utilisé la fonction concat().

Code:

---

1 2 3

tab1.concat tab2 tab1.concat tab3

---

La première ligne de code fonctionnait très bien. La seconde me concaténait mon tableau mais me créait en plus des tuples dans ma base de données. Impossible de savoir pourquoi. La solution que j'ai trouvée n'en est que plus loufoque. J'ai juste inversé ces deux lignes et plus aucun tuple ne s'est jamais inséré en base... Allez savoir pourquoi...

Le PC de mon beau père avait une surchauffe. Je pensais à de la poussière comme d'habitude mais en ouvrant la tour, j'ai retrouvé un lézard momifié encastré entre 2 bus PCI. Il habite dans l'île d'Oléron et laisse la porte ouverte sur le jardin.

Citation:

---

petit rappel pour la culture, le premier 'bug' est apparu a l'age de pierre de l'informatique quand une seule machine prennait une piece entiere et qu les ordinateurs fonctionnaient avec des lampes, lors d'une operation une bestiole trop curieuse est rentree dans la machine provoquant un faux contact ...

---

D'où le nom 'bug' (insecte en anglais) je suppose...

Un problème d'effondrement de la performance réseaux.
-A chaque visite, chez le client les performances étaient bonnes.
-La société ne pouvait que constater le bon fonctionnement en matinée.
-Nous nous sommes aperçu que les problèmes de perturbation réseaux se passaient en soirée mais pas systématiquement.

Ce n'est que par hasard qu'un employé constata que lors de la visite de la femme du patron en soirée, ses deux chiens teckel mordillais et léchaient la base de certaines prises réseaux et câbles.

Pour des raisons économiques, le patron avait soutraité l'installation du réseaux à un proche.

En tout début de mois nos serveurs sur site doivent faire une synchronisation avec nos serveur de données Web (entre 0h00 et 0h10)
Tous les tests fonctionnaient.
Seul la production plantait lamentablement tous les mois à cause d'un délais d'attente trop long (et il était impossible ou tout du moins trop risqué de retarder ces mise à jour).
Après plus d'un an de recherche (des centaines d'heures!!!) et des astreintes de nuit le 1ier du mois, un technicien France Télécom un peu plus zélé que les autres, mais surtout qui avait participé à la construction du bâtiment à trouvé la cause du souci.
Tenez vous bien :
Tous les locaux de l'immeuble disposaient d'un alarme, qui devait signaler son bon fonctionnement au centre de gestion deux fois par jour. Cette communication se fait par RTC et débutait chaque mois à 0h00, puis 12h01, puis 0h02 le lendemain, puis 12h03, 0h04, 12h05, … et ainsi de suite.
Le bâtiment ayant été construit au milieu des années 90, pour des raison de sécurité le boitier d'alarme avait été branché en dur (et dans les murs) en amont de la première prise téléphonique sur un raccordement inaccessible (ce que s'est souvenu le technicien FT !!!), ce qui empêchait la mise en place d'un filtre ADSL.
Donc notre connexion tombait deux fois par jours à des heure précise et justement à l'heure et à la minute précise, le premier jour du mois ou la connexion devait être active.
Personne ne s'en était aperçu car nos étions branchés en double WAN (et en VoIP pour la téléphonie). Et par manque de chance nous obligions (toujours pour des raison de sécurité à l'identification) notre serveur web à n'accepter que les authentifications faites à l'aide de l'IP qui tombait.

Pour corriger le problème nous avons simplement demandé à l'agence de télésurveillance de changer les heures d'appel.

Plus d'un an, pour s'apercevoir qu'une connexion tombait, après avoir démonté pendant plusieurs mois le prestataire technique, après avoir tenter de régler le problème avec le fournisseur ADSL qui ne trouvait aucun dysfonctionnement, avant de tomber par hasard au détour de l'installation de nouveaux postes téléphoniques sur un technicien qui connaissait le bâtiment et son câblage technique…
Des 100aines d'heures (de tous les cotés et pour tous les acteurs) de perdus.