Discussion :

[Idelways]

Quel est le bug le plus récalcitrant que vous ayez rencontré ?
Improbable ou impossible à reproduire, racontez-nous votre meilleure histoire de débogage



Si le débogage est l'art d'enlever les bogues, la programmation doit être l'art de les créer. Une expression chère à beaucoup de développeurs qui souligne à quel point le débogage d'une application peut être important et... problématique.

C'est ce que relate Patrick Thomson, un développeur blogueur qui raconte ce qu'il qualifie de "meilleure histoire de débogage qu'il ait jamais entendue".

Il s'agit d'une mésaventure vécue dans les année 80 par le père de l'auteur, avec un ordinateur ancestral utilisé pour imprimer d'importantes quantités de données.

Ce système fonctionnait comme un charme, sauf chez un client où l'opération d'impression s'arrêtait systématiquement au milieu, faisant perdre des heures de traitement et de productivité.

Seulement, les techniciens en charge de maintenir le système n'arrivaient pas, malgré de nombreuses tentatives, à reproduire le bug dans un environnement de test et décidèrent donc de faire appel à un « expert » in-situ, sur l'ordinateur incriminé.

Deuxième tentative (et deuxième arrêt donc), l'expert n'arrive toujours pas à localiser le problème mais remarque néanmoins qu'il se produit quand il y a beaucoup de monde dans la pièce dédiée à l'ordinateur.

Au bout de la troisième tentative, il remarque que l'arrêt se produit au moment où l'un des agents chargés de remplacer les cassettes magnétiques franchi un carreau de la dalle de sol.

Vous avez compris la fin de l'histoire, après de longues recherches infructueuses sur l'ordinateur, il s'avérait que le bug était provoqué par un court-circuit induit par la pression des pas des employés sur les câbles d'alimentation de l'ordinateur.

Cette situation n'a que très peu de chances de se reproduire aujourd'hui, mais elle nous rappelle que, en développement logiciel comme dans d'autres domaines, le problème ne se trouve pas toujours là où on le soupçonne.


Et vous ?

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

Source : Le blog de Patrick Thomson

[ArKam]

Il m'est arrivé approximativement la meme chose avec une imprimante qui pompé juste trop au moment de l'impression sur le courant.

[el_slapper]

Un coup de pelleteuse qui prive le service informatique d'une grande banque française de réseau pendant un jour et demi(fin des années 90).

Purement logiciel, un truc parfaitement reproductible mais tordu : les utilisateurs se voyaient proposer une liste déroulante, pouvaient forcer une autre valeur, avaient un message d'alerte(valeur erronée), forçaient quand même la validation, et boum plantage général. Evidemment, en test, il m'a fallu 10 jours avant de comprendre qu'il fallait passer par une valeur erronée(je selectionnais bêtement des valeurs standard dans la liste pour tester) pour tomber sur mon bug. 4 utilisateurs en 2 heures.

[Michaël]

Evidemment, en test, il m'a fallu 10 jours avant de comprendre qu'il fallait passer par une valeur erronée(je selectionnais bêtement des valeurs standard dans la liste pour tester) pour tomber sur mon bug. 4 utilisateurs en 2 heures.

une belle application du parallélisme

[toopac]

Bug qu'on m'a raconté un peu du même genre :

Tous les matins, vers 6-7h un serveur s'arrêtait. L'équipe s'est penchée sur ce problème pendant un bout de temps sans trouver la raison, jusqu'à ce qu'ils décident de regarder physiquement ce qu'il se passait à cette heure ci.

Ils arrivèrent donc à 6h du mat, et découvrirent alors la raison de l'arrêt du serveur.
C'etait la femme de ménage, qui débranchait le câble d'alim du serveur pour libérer un emplacement sur la multiprise dans le but de brancher son aspirateur...

[Auteur]

Bug qu'on m'a raconté un peu du même genre :

Tous les matins, vers 6-7h un serveur s'arrêtait. L'équipe s'est penchée sur ce problème pendant un bout de temps sans trouver la raison, jusqu'à ce qu'ils décident de regarder physiquement ce qu'il se passait à cette heure ci.

Ils arrivèrent donc à 6h du mat, et découvrirent alors la raison de l'arrêt du serveur.
C'etait la femme de ménage, qui débranchait le câble d'alim du serveur pour libérer un emplacement sur la multiprise dans le but de brancher son aspirateur...

et le serveur a supporté ces coupures brutales ??

[vpourchet]

c'est sympa comme tout comme bug !

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

perso je n'ai jamais eu d'insectes dans mon ordinateur


EDIT :

Un coup de pelleteuse qui prive le service informatique d'une grande banque française de réseau pendant un jour et demi(fin des années 90).

Je l'ai encore rencontre recemment ... travaux + pelleteuse + fibre ... des fois on se demande comment c'est possible, y'a t'il autant de cables sous nos pieds et aucun moyen de le savoir ?

[mortapa]

Je l'ai encore rencontre recemment ... travaux + pelleteuse + fibre ... des fois on se demande comment c'est possible, y'a t'il autant de cables sous nos pieds et aucun moyen de le savoir ?

lol pareil comme quoi c'est récurent ^^

[ProgVal]

Un de mes profs m'a parlé d'élèves qui avaient mis en place un projet, servant
à transporter (en hauteur) les sacs de courrier. Le système marchait très bien,
en tests, mais pas le reste du temps. Les élèves ont refait des tests, ça
marchait à nouveau très bien. Plus tard, ils ont observé les employés pendant
qu'ils accrochaient les sacs : au lieu de le mettre correctement, ils donnaient
un coup dans le sac, après l'avoir accroché.

[guidav]

Le PC qui redémarre quand on lance une impression avec Lotus 123. Reproductible, mais jamais résolu, et TRES agaçant.
Mais ça imprimait quand même

[kedare]

Un bug sur un de mes programmes qui plante au bout de plusieurs semaines, sans aucune message d'erreur ni rien au debogage, le programme quittait tout simplement pour une raison inconnue....

[Flaburgan]

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

bug veut tout simplement dire insecte.

[sevyc64]

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.

[Barsy]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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é

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 ?

[Tellen]

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.

[hsohaib]

On appelle ce genre de bug : "bugfoot"

[poringkiller]

une image chargée via une applet java qui servait de hitbox pour un jeu vidéo, seul le premier monstre à l'écran n'avait pas de collisions.
J'ai du demander à plusieurs contacts avant qu'on ne m'explique que au moment ou le monstre était créé, l'image n'était pas encore chargée en mémoire, et avait donc des dimensions de -1x-1 (donc verification de collision impossible :p)
qui a dit que java était lent xD?

[kapok]

il y a toujours le bug ultime, ultra difficile à reproduire et détecter...

il est situé entre la chaise et le clavier

[kolodz]

Un bug sur un logiciel de gestion commercial, au niveau de l'identification.

Version 1 : Tout le monde passe / (mais si l'utilisateur n'existe pas on le crée !)
Version 2 : Seul les utilisateurs enregistré peuvent passer, mais aussi ceux qu'on a détruit...(genre l'employé partie cher le concourant)
Version 3 (la mieux à mon gout): Si tu es enregistré tu doit connaitre ton mot de passe, sinon tu peux en taper un au pif.

Note important, une semaine entre chaque version et un dev à plein temps...

J'ai refusé de tester tout nouvelle version de cet "gestion commercial".

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

récalcitrant => plus de 3 semaines de debug.
improbable => la gestion de login/pass je pensais ça trivial...
non reproductible => Le développeur n'a jamais vue les problèmes lors de sa phase de test/codage.

Personnellement, j'espère que je ne reverrai plus jamais un cas aussi pitoyable.

[air-dex]

J'ai déjà eu un programme qui donnait aléatoirement des erreurs de segmentation à des endroits où il n'y en avait pas (d'après le débugger). Le même programme recompilé sans modifications sur le code source, avec les mêmes options de compilation et sur une autre machine de même configuration (Ubuntu 32 bits) marchait sans problème aux endroits critiques. Ce bug était très aléatoire (et donc très difficilement reproductible), quoiqu'il paraissait lié au temps d'utilisation du PC.

Sa résolution a été simple et radicale : changement de distribution Linux sur la machine posant problème. Ce bug avait été la goutte d'eau qui avait fait déborder le vase avec cette version d'Ubuntu (caca ), dont le fonctionnement était celui d'un Vista à l'état primitif.