COMPTOIR
register

Composé par ————— —— 15028 vues

Trop de bugs ? La génération automatique de patchs est en route !

Nous vous parlions cet été de détection automatique de bugs, il est question ici de résolution automatique de ces derniers. En effet, des chercheurs de l'Université de Californie (San Diego) ont remarqué que les patchs de correction de bugs sont souvent des correctifs courts (quelques lignes, par exemple pour vérifier qu'un objet existe en mémoire avant d'y accéder) et génériques, d'où l'idée de les automatiser.

 

Il existait déjà auparavant des correcteurs permettant de suggérer une template au programmeur, mais cette dernière devait être au préalable manuellement ajoutée. Ici le programme, nommé Genesis, s'inspire de patchs déjà codés pour définir ses propres propositions. Verdict : face à la machine, l'humain déclare 5 à 10 modèles différents, là ou la machine en voit 85, ce qui permet de corriger deux fois plus d'erreurs ! Sur un jeu de test spécialement dédié à cet effet, Genesis a su corriger 21 fautes sur 49, là où le meilleur algorithme utilisant des templates manuelles n'en trouvait que 11.

D'un point de vue théorique, Genesis sélectionne plusieurs templates candidats, pour ensuite les classer par efficacité sur des programmes d'exemple, et ne conserver que les 500 meilleurs. Elles-mêmes sont raffinées par la suite afin de minimiser les doublons.

 

Bien que Genesis ne soit pas à proprement parler capable de comprendre le code (il reconnait simplement certains motifs), il s'agit d'un premier pas dans ce sens. Pour le moment, le seul langage supporté est le Java, ce qui limite son utilisation. Cependant, si ce système fait ses preuves, une adaptation sur d'autres langages est plus que probable.

 

insecticide

Au comptoir, pas besoin de programme spécialisé contre les bugs !

Un poil avant ?

Gamotron • Ça colle entre Bayek et Cléopâtre

Un peu plus tard ...

La beta de CoD WWII en test

Les 15 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Nicolas D., le Mardi 03 Octobre 2017 à 16h40  
par Janus31 le Mardi 03 Octobre 2017 à 10h59
il y a peu de chance qu'ils aient jamais utilisé gdb (ni meme gcc ni ... bref aucun des trucs du freeware et OpenSource) ni pour l'OS ni pour les applications (Office et autres).
Je dirais même qu'au lieu de rejoindre (ou de rester parallèle) au reste du monde informatique ils ont délibérément pris le parti de s'en écarter pour que Vindoz + Office + (etc) restent des solutions propriétaires ... justifiant alors leur commerce.
Et pareil pour Mac, toutes ces boites sont faites pour vendre, pas pour faire cadeau à l'humanité d'un OS + Applis gratuits.
Libre non, mais heureusement que dans Visual studio (XCode je ne connait pas) tu as un débuggueur, ou QTcreator aussi. Si la méthode fait ses preuves, ils l'intégreront (mais qui sait quand...) et sur les serveurs, pas mal de choses se font sous Tux !
par Janus31, le Mardi 03 Octobre 2017 à 11h18  
+EDIT : pour ceux qui s'intéressent aux devs, il y a Windev de PC Soft (à Montpellier ma ville natale ) qui fait très bien le job, depuis une "analyse" jusqu'à la prod d'un code, que ce soit pour l'informatique de gestion (base de donnée) ou des applis Web, c'est assez complet.
Et coté tarifs, PC Soft vous envoie a ses frais la version, avec une période d'essai (à négocier au téléphone) et retour tjrs a ses frais.
Perso quand j'ai débuté comme Indépendant, j'ai commandé puis finalement retourné le produit alors que PC Soft (sachant que je débutais) m'a proposé de le garder ... sans leur devoir quoi que ce soit (donc gratos mais sans les mises a jour vers versions ultérieures).
C'est un geste du département "marketing" qui méritait que je vous en parle, d'où cet "Edit".
J'suis pas informaticien du tout mais scientifique de formation (Automaticien), j'ai donc pour habitude d'aller triturer les codes, les OS, les piles réseaux, désassembler des binaires dont on a perdu les codes sources (sic !) pour du spatial embarqué (entre autres), bref j'suis un bidouilleur pas un PRO
par Janus31, le Mardi 03 Octobre 2017 à 10h59  
par Nicolas D. le Lundi 02 Octobre 2017 à 18h58
Effectivement ça doit être plus costaud avec un langage compilé, mais pas impossible. Le désassemblage est interdit pour l'utilisateur, j'espère que les devs on accès à un débogueur type GDB, sans quoi je comprends mieux la stabilité légendaire de Windows
Heu ... comment te dire ... Vindoz est issu d'un DOS (pour Dirty OS ?) racheté à l'age de bronze à IBM par CroCroSoft qui vend sa solution "Visual truc machin" donc il y a peu de chance qu'ils aient jamais utilisé gdb (ni meme gcc ni ... bref aucun des trucs du freeware et OpenSource) ni pour l'OS ni pour les applications (Office et autres).
Je dirais même qu'au lieu de rejoindre (ou de rester parallèle) au reste du monde informatique ils ont délibérément pris le parti de s'en écarter pour que Vindoz + Office + (etc) restent des solutions propriétaires ... justifiant alors leur commerce.
Et pareil pour Mac, toutes ces boites sont faites pour vendre, pas pour faire cadeau à l'humanité d'un OS + Applis gratuits.
Je me suis toujours refusé à développer quoi que ce soit avec les suites payantes pour ne pas répercuter le coût sur MES prestations ponctuelles, étant Indépendant depuis <10ans ni même auparavant (Consultant Altran).
On me donnait chaque fois un PC (sous Vindoz), j'installais Cygwin, j'ai fais mon propre atelier
par Nicolas D., le Lundi 02 Octobre 2017 à 18h58  
par Janus31 le Lundi 02 Octobre 2017 à 16h45
Le faire avec du code Java est "presque une gageure", comme avec tous les codes pseudo-compilés (nécessitant une Runtime ou un interpréteur).
[...]
Le seul moyen de corriger "automatiquement" un soft (en remontant l'erreur détectée au niveau des codes sources sinon bonjour la série de patchs !) consiste à dés-assembler les binaires ... OR ceci est formellement interdit ... et donc cette "activité" ne peut faire l'objet d'un outil ni commercial ni freeware mais seulement très confidentielle (cas de force majeure).
Effectivement ça doit être plus costaud avec un langage compilé, mais pas impossible. Le désassemblage est interdit pour l'utilisateur, j'espère que les devs on accès à un débogueur type GDB, sans quoi je comprends mieux la stabilité légendaire de Windows
par Janus31, le Lundi 02 Octobre 2017 à 17h11  
par Scrabble le Lundi 02 Octobre 2017 à 12h07
Ah, Valgrind, Rational Purify, les UMR(Uninitialized Memory Read) qui donnaient un aspect aléatoire au déroulement des programme C++, que de souvenirs Bien content d'être passé à Java, ça permet de s'affranchir de toutes ces erreurs de gestion mémoire qui sont si chiantes à la longue.
+1 : cela a été une des raisons des géniteurs de Java, la garbage collector intégré, mais qui pose un problème en programmation puisque personne ne maitrise (au sens temporel, prédictif) la "destruction" d'un objet (et libération de la mémoire associée).
C'est d'ailleurs un des principaux freins(*) de Java pour le secteur Industriel parmi les langages-objets (et pas "langage à objets" comme l'est Ada, par exemple).

(*) si on ne parle pas du fait que tous les objets Java peuvent être "castés" selon l'humeur du programmeur (et SA connaissance d'un JavaObject et son héritage), ce qui lui enlève tout l'intérêt du typage fort attendu ... qu'on n'obtient qu'en C++ (en bannissant les casts ce qu'un simple script Tcl peut vérifier pour l'analyse du code source). Quand à la gestion des objets (partage de références puis destruction lors de la dernière utilisation d'un objet) on peut utiliser les Smart-Pointers (le code source est free) c'est infiniment simple et perso j'ai été amené à écrire des scripts sed/awk pour patcher des softs (> 15ans)
par Janus31, le Lundi 02 Octobre 2017 à 16h45  
"(...)le seul langage supporté est le Java (...) une adaptation sur d'autres langages est plus que probable"
Permettez moi d'en douter, car si la chose s'avérait possible, depuis le temps qu'existent les langages informatiques (basic, c, fortran, ada, etc) cela serait chose faite
Le faire avec du code Java est "presque une gageure", comme avec tous les codes pseudo-compilés (nécessitant une Runtime ou un interpréteur).
Le seul moyen de corriger "automatiquement" un soft (en remontant l'erreur détectée au niveau des codes sources sinon bonjour la série de patchs !) consiste à dés-assembler les binaires ... OR ceci est formellement interdit ... et donc cette "activité" ne peut faire l'objet d'un outil ni commercial ni freeware mais seulement très confidentielle (cas de force majeure).
Et ré-écrire tous les codes existants ici et là depuis plus de 50 ans nécessiterait du rétro-ingénierie pour remonter aux diagrammes UML (ou autre formalisme) dans des métas-langages permettant la génération automatique de code.
Donc à mon avis le programme "Genesis" restera "cantonné (*)" au domaine des applis portées, sur mobile, jamais dans les secteurs Industriels.

(*)c'est déjà pas mal
par Nanabozo732, le Lundi 02 Octobre 2017 à 13h02  
par Jte Roule D3ssus le Lundi 02 Octobre 2017 à 06h59
La "révolution" ne sera pas hardware mais bien software
On le voit depuis quelques années avec le machine learning, voiture autonome et l'ia en général.
Les progrès en quelques années ont été fulgurant et exponentiel.
Oui et non, pour que le software offre des choses nouvelles et fulgurantes c'est beaucoup mieux si le matériel est optimisé et conçu pour... et vice-versa.
par Scrabble, le Lundi 02 Octobre 2017 à 12h07  
Ah, Valgrind, Rational Purify, les UMR(Uninitialized Memory Read) qui donnaient un aspect aléatoire au déroulement des programme C++, que de souvenirs Bien content d'être passé à Java, ça permet de s'affranchir de toutes ces erreurs de gestion mémoire qui sont si chiantes à la longue.
par Un programmeur d'Ile-de-France, le Lundi 02 Octobre 2017 à 12h04  
par Un adepte de Godwin d'Ile-de-France le Lundi 02 Octobre 2017 à 09h07
Pour les race conditions c'est pas si sûr, un outil pourrait très bien imaginer des scénarios type A prend le lock B le déverouille, etc. et en trouver un qui foire.
Ce que vous décrivez est un bogue du type "dead lock" (conflit d'utilisation d'un sémaphore entre deux fils d'exécution (threads) conduisant à un blocage des dits fils), pas une "race condition" qui est une compétition pour l'usage d'une même ressource (non protégée par un sémaphore car se produisant dans un même fil d'exécution), en général suite à un (dés)ordre imprévu/accidentel dans l'appel de fonctions "callback".

Le problème des outils de débogage tels que celui décrit dans l'article est qu'ils ne tiennent pas compte de la structure ni du fonctionnement (normal et anormal) du programme et ne se basent que sur des recettes ayant statistiquement été efficaces dans certains cas (les plus simples).

Seul un être humain (formé, compétent et expérimenté, évidemment) est aujourd'hui (et je le gage, pour quelques décennies encore) capable de comprendre et de conceptualiser le fonctionnement intime d'un programme, ainsi d'ailleurs que de prévoir ce qui pourrait foirer (surtout si le programme accepte des entrées provenant d'autres humains, et en particulier de madame Michu)...
par Xorg, le Lundi 02 Octobre 2017 à 11h07  
Faites du C et débuguez avec GDB et Valgrind, y'a que ça de vrai !
J'aime beaucoup Valgrind car il peut afficher toutes les erreurs mémoire, et je suis content que si Valgrind est content. Pour moi, un programme qui présente des dépassements de mémoire, c'est synonyme d'une segfault qui va se produire, le genre de truc qui n'arrive jamais à soi mais toujours sur les machines des autres.
Après, on aime ou on n'aime pas le C, mais je trouve qu'il donne de meilleurs bases aux débutants que le Java. Prenez un type qui passe du Java au C, il va enchaîner les erreurs triviales (genre variable non-initialisée ). Personnellement, je trouve ça plus instructif de corriger un bug par soi-même que de laisser ça à Genesis ; après, ça donne de mauvaises habitudes aux développeurs...
par UpsiloNIX, le Lundi 02 Octobre 2017 à 09h47  
par Un programmeur d'Ile-de-France le Lundi 02 Octobre 2017 à 08h34
Mouais... Bonne chance à un quelconque logiciel correcteur pour détecter une "race condition", un problème de sémaphore mal placé, ou un des dizaines d'autres types de bogues, que seul un programmeur humain chevronné peut trouver et corriger correctement !

A noter, par ailleurs, que le compilateur serait un meilleur endroit pour placer de tels algorithmes de détection de bogues "de débutant" (par exemple, un compilateur C pourrait facilement détecter la première utilisation d'un pointeur dans une fonction et émettre un avertissement si la non-nullité de ce pointeur n'a pas encore été vérifiée)...
T'inquiète pas, tu as encore quelques année avant que les développeurs humanoïdes ne disparaissent
par Un adepte de Godwin d'Ile-de-France, le Lundi 02 Octobre 2017 à 09h07  
Niveau patch intelligent il y a aussi http://coccinelle.lip6.fr/ qui est pas mal utilisé dans le noyau Linux.
C'est en tout cas une bonne idée puisqu'il est vrai que pas mal de patch consiste souvent un `if` pour tester le pointeur/la référence avant de le/la déréférencer.
par Un programmeur d'Ile-de-France le Lundi 02 Octobre 2017 à 08h34
Mouais... Bonne chance à un quelconque logiciel correcteur pour détecter une "race condition", un problème de sémaphore mal placé, ou un des dizaines d'autres types de bogues, que seul un programmeur humain chevronné peut trouver et corriger correctement !

A noter, par ailleurs, que le compilateur serait un meilleur endroit pour placer de tels algorithmes de détection de bogues "de débutant" (par exemple, un compilateur C pourrait facilement détecter la première utilisation d'un pointeur dans une fonction et émettre un avertissement si la non-nullité de ce pointeur n'a pas encore été vérifiée)...
Pour les race conditions c'est pas si sûr, un outil pourrait très bien imaginer des scénarios type A prend le lock B le déverouille, etc. et en trouver un qui foire.

Concernant les compilateurs, clang incorpore il me semble un analyseur statique de code type cppcheck.