Discussion:Analyse dynamique de programmes

Démarche de relecture sur "Analyse dynamique de programmes"

Bonjour à tous, Tout d’abords bravo à vous, pour être allé au bout de l’exercice, dans le cadre de Projet informatique 2.0. Je ne suis absolument pas rodé au travail de relecture, que ce soit en termes de méthodologies ou de pertinences (somme toute relative). Ne sachant pas trop par quel bout entreprendre cette tâche je vais essayer dans un premiers temps de partir de votre travail et essayer de vous partager les interrogations que me suscitent votre sujet, que ce soient sur des aspects traités ou non. Il n’y aura là aucune attaque personnelle. J’essaierai également de vous partager des références qui pourraient appuyer mes interrogations ou remarques. Cdt, TV974 (discuter) 11 janvier 2019 à 11:15 (CET)TV974

Bonjour !

Toute remarque est bonne à prendre :D (Du moment qu'elle soit accompagné d'un contexte bien sûr).

Merci d'avance pour votre contribution !

Haydgoki (discuter) 13 janvier 2019 à 19:16 (CET)

Les limites de l'analyse dynamique de programme

Il s'agit de relativiser l'analyse dynamique de programme. Serait par essence perfectible. Selon Edsger Dijkstra "Les tests de programme peuvent être utilisés pour montrer la présence de bugs, mais jamais pour montrer leur absence"

• (en) E. Dijkstra, « Structured programming », The ACM Digital Library,‎ janvier 1979, ??-?? (ISBN 0-917072-14-6, DOI ??)

TV974 (discuter) 14 janvier 2019 à 08:01 (CET)TV974

Bonjour,

Nous n'avons pas bien compris le sens de la remarque. Quant à la citation de cet article, nous ne comprenons pas non plus dans quoi elle devrait s'inscrire.

Dans l'attente d'une future réponse,

Haydgoki (discuter) 13 janvier 2019 à 19:16 (CET)

Réponse commentaire: Les limites de l'analyse dynamique de programme

Bonjour, n'aurait-il pas été aussi intéressant de parler des limites de l'analyse dynamique des programme? (Voilà l'objet de la remarque.) Cela ne pourrait-il pas constituer un complément à votre article? Concernant le document il sert principalement ici à sourcer la citation. NB: Nous disposons à présent d'une méthodologie, je tâcherai donc de mieux structurer mon travail de relecture. Cdt, TV974 (discuter) 14 janvier 2019 à 08:01 (CET)TV974

Bonjour,

En effet nous n'avons pas abordé cette thématique car elle nous paraissait assez évidente. Néanmoins il serait en effet judicieux de parler des failles et des limites de l'analyse dynamique. Nous allons peut-être rajouter un petit encart à ce sujet. Cordialement Haydgoki (discuter) 18 janvier 2019 à 15:02 (CET)

Bonjour,

Pour tenter de vous préciser mon idée c'est qu'est ce qu'on peut et ne peut pas demander à l'analyse dynamique? TV974 (discuter) 18 janvier 2019 à 16:06 (CET)TV974

Relecture sur la forme du Résumé introductif (18.01.19)

Suite à ma relecture voici les éléments que j'ai pu noter:

• Orthographe: « ou non à des zones mémoire interdites, » => « ou non à des zones mémoires interdites, »
• L'usage de l'italique semble mal employé.
• Usage du logo Valgrind inapproprié il ne s'agit pas d'une page wikipédia sur Valgrind
• Il est fait mention de: "l'utilisation de la mémoire ou encore l'énergie dépensée par le programme. " avec un lien bleu pour mémoire vive, soit le lien est à revoir soit la phrase à préciser. (Ajouter le 22.01.19)

TV974 (discuter) 23 janvier 2019 à 14:06 (CET)TV974

Bonjour, tout d'abord merci pour les nombreuses remarques !

* Je me demande ou est-ce que l'italique a été mal employé ?

La seule indication que nous avons eu à propos de l'italique c'est qu'il doit être appliqué sur les mots qui ne sont pas français.

Soit les mots "dynamic program analysis" et "fuzzer" dans l'introduction.

* Ensuite pour le logo valgrind c'est une question que nous nous étions posé au moment de le mettre. Nous avions fait le choix de mettre une image concernant un grand outil de l'analyse dynamique de la même manière qu'on peut trouver un mousquetaire sur la page wikipedia des armes à feu -> https://fr.wikipedia.org/wiki/Arme_%C3%A0_feu

* Et finalement merci pour les fautes d'orthographes sur les différentes parties, je vais essayer de tout corriger !

--Tamolegro (discuter) 20 janvier 2019 à 13:45 (CET)

Bonjour,

* Eratum pour l'italique effectivement, l'usage de l'italique est correcte. "##L'italique est rarement utilisé : mots en langue étrangère, titres d'œuvres, noms de bateaux, etc."

* Pour ce qui est du logo je pense définitivement qu'il n'a pas sa place dans le résumé introductif. Quand bien même il s'agirait d'"un grand outil de l'analyse dynamique", Valgrind n'est pas le sujet ici et il n'y est fait mention nulle part. C'est comme si pour le résumé introductif dans la page Wikipédia de l'Analyse statique des programmes ->https://fr.wikipedia.org/wiki/Analyse_statique_de_programmes il y avait la photo de Tony Hoare, ou dans l'Analyse transactionnelle -> https://fr.wikipedia.org/wiki/Analyse_transactionnelle , la photo d'un divan -> https://fr.wikipedia.org/wiki/Divan_(meuble) . Sur la page que vous avez donné -> https://fr.wikipedia.org/wiki/Arme_%C3%A0_feu l'image de l'arme à feu du mousquetaire vient clairement illustrer le résumé introductif "Depuis quelques siècles, à partir de la Renaissance tardive, les armes à feu sont devenues les armes prépondérantes de l'humanité." elle donc se justifier. Il s'agit là d'illustrer l'arme dans son époque. TV974 (discuter) 21 janvier 2019 à 09:08 (CET)TV974

Bonjour, je ne vois pas le problème avec le fait d'utiliser cette image pour illustrer l'analyse dynamique de programme vu que c'est un concept abstrait et que l'image a un rapport avec. Sur la page de la médecine par exemple : https://fr.wikipedia.org/wiki/M%C3%A9decine, on peut y retrouver une illustration ayant autant de rapport avec la page, que notre illustration avec notre page.

Si il y a une "charte" sur les illustrations et que nous ne la respectons pas, je veux bien changer d'image, mais pour le moment, cela ne me gêne pas du tout.

Cordialement, Haydgoki (discuter) 21 janvier 2019 à 17:53 (CET)

Bonjour,

je préfère prendre comme référence un article qui semble faire consensus "La boite de conserve" -> https://fr.wikipedia.org/wiki/Boite_de_conserve (article jugé de qualité par la communauté). Les images utilisées dans le résumé introductif semblent parfaitement appropriées et en liens avec ce dernier. L'image utilisé pour la page "Médecine" -> https://fr.wikipedia.org/wiki/M%C3%A9decine n'y a pas sa place. Sa place est plus approprié sur une page "Pédiatrie" -> https://fr.wikipedia.org/wiki/P%C3%A9diatrie. Les images ne sont pertinentes qui si elles viennent illustrer un propos. Ce n'est pas le cas dans votre résumé introductif pour le logo Valgrind. Après cela je vais être à court d'arguments pour ce problème forme, et cela vous deviendra peut plus parlant lorsque nous aborderons le fond.

Cordialement TV974 (discuter) 22 janvier 2019 à 09:39 (CET)TV974

Bonjour,

• suggestions de liens bleu pour optimiser

TV974 (discuter) 1 février 2019 à 07:20 (CET)TV974

J'ai bleui optimiser :)

--Tamolegro (discuter) 2 février 2019 à 13:24 (CET)

Relecture sur la forme de "Analyse pour la vitesse d'exécution" (18.01.19)

Suite à ma relecture voici les points que j'ai pu noter:

• Orthographe: "de données utile" => "de données utiles" | "chaque fonction à été appelée." => "chaque fonction a été appelée"
• Lien bleu: performances
• Argument d'autorité: Lorsque que l'on veut améliorer la vitesse d'exécution d'un programme, l'un des outils principal du développeur est le profilage statistique (Sampling profiler). => A reformuler
• Usage du pronom personnel "ON" est à proscrire. Wikipédia:Style encyclopédique
• attention à l'usage des terme anglo-saxon: sample profiler => traduire en français? sample profiler => traduire en français ?
• "C'est pourquoi il existe des Latency profiler qui se concentrent sur ces ralentissements6,7,8." => aucune page renseigné pour la ref 8
• Français: "à fonctionner pendant longtemps" => à reformuler

TV974 (discuter) 23 janvier 2019 à 14:06 (CET)TV974

Bonjour, j'ai pris en note tous les commentaires et je les ai incorporé, sauf pour le pronom "on" et la référence, je le ferai plus tard

Haydgoki (discuter) 21 janvier 2019 à 18:23 (CET)

Je pense avoir corrigé tous les "on" et la référence :)

--Tamolegro (discuter) 29 janvier 2019 à 19:08 (CET)

Relecture sur la forme de "Analyse de la consommation de mémoire" (18.01.19)

Suite à ma relecture voici les points que j'ai pu noter:

• orthographe: fonction à été appelée. => a été appelée
• Usage du pronom personnel "ON" est à proscrire Wikipédia:Style encyclopédique
• Lien bleu: méthode

TV974 (discuter) 23 janvier 2019 à 14:07 (CET)TV974

J'ai pris en compte tous les commentaires et j'ai tout modifier sauf pour le "on", je le ferai plus tard

Haydgoki (discuter) 21 janvier 2019 à 18:24 (CET)

Normalement c'est fait :)

--Tamolegro (discuter) 30 janvier 2019 à 01:12 (CET)

Relecture sur la forme de "Analyse énergétique" (18.01.19)

Suite à ma relecture voici les points que j'ai pu noter:

• Lien Bleu: machines virtuelles , cloud , granularité , consommation énergétique des programmes
• Remplacer "hardware" par "matérielles"
• manque de source: Certaines technologies essaient même de fournir une estimation de la consommation énergétique pour une ligne de code donnée. => Ah Oui? source, exemple? comment procèdent elles?
• possible problème de sens: "Problème de sens: Bien que l'on puisse réduire la fréquence des processeurs ou encore se tourner vers des machines virtuelles hébergées dans le cloud, réduire directement la consommation énergétique des programmes reste une solution que l'on peut souvent adopter en parallèle. " => cela laisse penser que la virtualisation permet de réduire la consommation énergétique. Ce n'est pas tant la virtualisation (hébergé ou non)qui permettrait de réduire la consommation énergique mais plutôt la mutualisation des ressource matérielles, non?

TV974 (discuter) 23 janvier 2019 à 14:07 (CET)TV974

Je pense avoir tout fait SAUF la source

--Tamolegro (discuter) 30 janvier 2019 à 01:14 (CET)

Bonjour, j'ai rajouté la source ! Néanmoins ils ne précisent pas comment ils calculent la consommation ligne par ligne. Je suppose qu'ils partent des instructions induites par ligne puis qu'en fonction du modèle énergétique ils arrivent à en dégager une consommation. Mais comme ce n'est pas expliqué, je ne peux pas l'écrire et encore moins le sourcer.

Cordialement, Haydgoki (discuter) 30 janvier 2019 à 11:22 (CET)

Relecture sur la forme des parties 4 / 5 / 6

Bonjour, j'ai relevé quelques fautes de forme sur vos chapitres 4 / 5 / 6.

Les voici :

• Dans analyse de teinte : Dans les deux puces, je commencerai par une majuscule.
• Je mettrai en lien interne RAM > Mémoire_vive; Registre > Registre#En_informatique; Malware, est en anglais (Italique ?) ou traduction française > Logiciel_malveillant; faille > Vulnérabilité_(informatique)
• « L'avantage de mettre en place un système directement sur le matériel, est que l'on peut contrôler beaucoup plus facilement les données qui passent dans chaque composant, avant que le programme puisse éviter la détection au préalable par une astuce quelconque (avec un hook par exemple)23 »

Cette phrase n'est pas très compréhensible, vous parlez d'une analyse sur le matériel puis « avant que le programme puisse éviter la détection ». Comment le programme peut-il outrepasser le matériel ? Peut-être faut-il reformuler cette phrase que je n'ai pas bien comprise.

• Vous parlez aussi de ralentissement du programme dû à l'émulation, Y a t-il un seuil qu'il ne faut pas dépasser, ce ralentissement peut-il être paramétré ?
• L'usage du « on » est très présent dans votre texte, il est à éviter.
• Dans la première puce : « l'on veut tester qu'une application à laquelle on aurait fournit des droits », fournis prend un s et non un t.

« Hook », je le mettrai en italique.

• Les analyses de teinte sont régies par des politiques qui dictent leur comportement, en fonction des besoin : Leurs comportements, et un s à besoin.

JPayrat (discuter) 28 janvier 2019 à 09:53 (CET)

Il reste a faire :

* « L'avantage de mettre en place un système directement sur le matériel, est que l'on peut contrôler beaucoup plus facilement les données qui passent dans chaque composant, avant que le programme puisse éviter la détection au préalable par une astuce quelconque (avec un hook par exemple)23 »

* Cette phrase n'est pas très compréhensible, vous parlez d'une analyse sur le matériel puis « avant que le programme puisse éviter la détection ». Comment le programme peut-il outrepasser le matériel ? Peut-être faut-il reformuler cette phrase que je n'ai pas bien comprise.

* Vous parlez aussi de ralentissement du programme dû à l'émulation, Y a t-il un seuil qu'il ne faut pas dépasser, ce ralentissement peut-il être paramétré ?

--Tamolegro (discuter) 30 janvier 2019 à 01:32 (CET)

J'ai essayé de corriger la phrase en y mettant une traduction de citation qui semblait pertinente. Il faudrait me dire si vous comprenez mieux. Pour les questions sur l'émulation je n'ai malheureusement pas les réponses.

Haydgoki (discuter) 30 janvier 2019 à 13:30 (CET)

Dans deboggage : Deboggage s'écrit Débogage

• Liens bleuis : Code source > Code_source; Compilateur > Compilateur; Trap mériterai d'être développé. Objet > Programmation_orientée_objet

« Ce type de programme ne demande aucune modification du code source et va générer des fichiers d'entré de manière aléatoire en pour faire planter le code30,31. Mais il existe aussi des fuzzer qui exécutent le code source » Dans débogage, vous dites que le fuzzer ne modifie pas le code, mais est-ce qu'il exécute le programme ? Est-il différent des fuzzer qui exécute le code source ?

Après vous indiquez un bout de code qui peut faire planter le programme. Est-il injecté dans le programme ? Je ne comprend pas bien le sens de ce paragraphe.

• « des fichiers d'entré », entrée prend un e à la fin.
• « son temps d'exécution et trouver des bugs plus complexe », complexe prend un s à la fin.
• On retrouve deboggueur avec 2 g au lieu d'un seul et un u à la fin, debogueur.
• Prints devrait être en italique.
• Dans la première puce, executé doit prendre un e à la fin.

C'est tout pour le moment :)

JPayrat (discuter) 22 janvier 2019 à 12:20 (CET)JPayrat

* Pour la seconde remarque je m'étais mal exprimé, les fuzzer exécutent tout le temps le code source, je voulais simplement dire que certain instrumentalisé le code avant de l'exécuter pour savoir quelles parties du code on été exécuté.

* Le code doit être vu comme un programme complet que l'on voudrait "tester" avec un fuzzer. J'ai essayé de reformuler le petit paragraphe qui suivait.

Merci pour tous ces commentaires. J'espère avoir résolu tout ceux que je n'ai pas mentionné :)

--Tamolegro (discuter) 30 janvier 2019 à 01:55 (CET)

Bonjour

• La Référence 35 n'est liée à aucun document.
• La Référence 36 doit comprendre un erreur le lien ne se fait pas correctement

cdt, TV974 (discuter) 1 février 2019 à 14:34 (CET)TV974

Bien vu !

J'ai ajouté les deux références

--Tamolegro (discuter) 2 février 2019 à 13:39 (CET)

Bonjour,

Ref 37 il manque le "1" au tout début du n° de DOI

"La manière courante de déboguer son code est en général de l'instrumentaliser à la main" => Cette phrase serait à reformuler dans son ensemble, de plus le "son" pose problème est devrait être remplacé par "du".

cdt,

TV974 (discuter) 4 février 2019 à 08:15 (CET)TV974

Je pense que c'est bon pour les deux remarques

--Tamolegro (discuter) 10 février 2019 à 20:44 (CET)

Relecture sur la forme "Commentaire général sur la page" (23.01.19)

Bonjour,

La partie "Application" ne semble pas suffisamment étayé pour faire l'objet d'une partie. Suggestion pour les sources: Afin d'apporter plus de lisibilité aux relecteurs l'utilisation de la plume peut être intéressante, pour mettre en valeur les sources que vous avez utilisé. Elle peut aussi mettre en valeur votre travail.

Cdt, TV974 (discuter) 23 janvier 2019 à 11:22 (CET)TV974

Bonjour,

En effet l'utilisation de la plume serait assez intéressante. Vous n'auriez pas un article dessus précisant son utilisation ? En effet j'aimerai qu'elles soient autogenérées grâce aux références, car à chaque modification du texte il faudrait revérifier à la main tous les articles ajoutés ou supprimés.

Quant à la partie application, je suis d'accord sur le fait qu'elle ne soit pas suffisante pour faire une partie à elle seule. Néanmoins je pense que la laisser est plus facile pour de futures contributions, vu que le plan est déjà annoncé. Il suffirait alors de compléter cette partie.

Cordialement, Haydgoki (discuter) 30 janvier 2019 à 13:42 (CET)

Bonjour

Vous pouvez aller sur l'article CertiKOS.

Je ne sais pas si cela peut être autogérer par le référencement mais, je suis aussi intéresser par cette solution.

cdt,

TV974 (discuter) 1 février 2019 à 12:38 (CET)TV974

Relecture sur le Fond "Commentaire général sur la page" (23.01.19)

Bonjour,

Dans cette rubrique nous tâcherons de vous faire des suggestions de plans pour restructurer et approfondir des aspects (traités ou non), relatives à votre sujet.

Cdt, TV974 (discuter) 23 janvier 2019 à 11:31 (CET)TV974

Si on regarde votre plan, on s’aperçoit que vous traitez différents cas spécifiques d'analyse dynamique, or un premier chapitre expliquant

ce qu'est l'analyse dynamique et les différents moyens d'analyse, statique, dynamique, avec insertion de code ou sans insertion (avec des logs et des arrêts programme pour constater les états).

En quoi l'analyse dynamique est-il différente des tests ? Je pense que cela peut être pertinent d'aborder ce sujet.

Cet article aborde la différence entre l'analyse statique et dynamique par exemple.

* (en) P. Godefroid, P. de Halleux, A. V. Nori, S K. Rajamani, W. Schulte, N. Tillmann et M Y. Levin, « Automating Software Testing Using Program Analysis », IEEE Software,‎ août 2008, p. 31 (ISSN 1937-4194, DOI 10.1109/MS.2008.109)

On peut également trouver la différence entre un profiler statistique et un profiler qui injecte du code :

https://www.delphitools.info/samplingprofiler/

JPayrat (discuter) 23 janvier 2019 à 14:06 (CET)

Bonjour

je partage ce qui a été écrit précédemment. Vous êtes parti directement aux cas d'usages. Les suggestions du commentaire précèdent pourraient s'inscrire dans la partie "Présentation de l'analyse dynamique" de la suggestion de plan suivant:

--1.Présentation de l'analyse dynamique

(ce que c'est | comparaison possible avec l'analyse static | ce que permet et ne permet pas l'analyse dynamic | peut être évoqué DSE Dynamic Symbolic execution)

Exemple de sources: https://www.researchgate.net/profile/Chris_Hankin/publication/265352570_Principles_of_Program_Analysis/links/00b7d52ce629e3c1c3000000/Principles-of-Program-Analysis.pdf?origin=publication_detail

* (en) E. Schwartz, T. Avgerinos et D. Brumley, « All You Ever Wanted to Know about Dynamic Taint Analysis and Forward Symbolic Execution (but Might Have Been Afraid to Ask) », 2010 IEEE Symposium on Security and Privacy,‎ mai 2010, p. 317-331 (ISBN 978-1-4244-6894-2, ISSN 1081-6011, DOI 10.1109/SP.2010.26)

--2.Analyse de flux de donnée (Data flow analysis)

-----2.1Analyse de teinte (Taint analysis)

http://lille1tv.univ-lille1.fr/tags/video.aspx?id=f8ff024f-9b38-47b5-8205-384d8771d617

-----2.2Analyse de vivacité (liveness analysis)

-----2.3Analyse de plage (Range analysis)

--3.Applications possibles

-----3.1Débogage

-----3.2Consommation énergétique

-----3.3Optimisation de code

(vos différents profileurs)

-----3.4Pédagogique

Votre travail semble parfaitement intégrable dans la partie 3.

TV974 (discuter) 23 janvier 2019 à 15:46 (CET)TV974

Relecture de fond : Dans quels cas sont utilisé les profilers ?

* (en) H K. Cho, R. Hank, D. Bruening, T. Moseley et S. Mahlke, « Instant profiling: Instrumentation sampling for profiling datacenter applications », Proceedings of the 2013 IEEE/ACM International Symposium on Code Generation and Optimization (CGO),‎ février 2013, p. 31 (ISBN 978-1-4673-5525-4, DOI 10.1109/CGO.2013.6494982)

Dans cette source il a été étudié l'utilisation de profilers instantanés dans les data center. Au lieu d'instrumenter (injecter du code) toute l'exécution, le profilage instantané entrelace périodiquement l'exécution native et l'exécution instrumentée selon des paramètres de durée et de fréquence de profilage configurables. Il réduit en outre la dégradation de latence des phases de profilage initiales en pré-remplissant un cache de code logiciel. Nous évaluons les performances et l'efficacité de cette nouvelle technique de profilage sur la suite de tests de performances SPEC CINT2006 et sur deux tests de performances d'applications de centre de données. Nous montrons qu’il est bien adapté au déploiement dans des centres de données en entraînant moins de 6% de ralentissement et 3% de temps système supplémentaire en moyenne.

JPayrat (discuter) 23 janvier 2019 à 14:45 (CET)

Relecture de Fond : Ralentissement de l'application dû au profiler, quelles limites ?

Bonjour,

On peut trouver le délai maximal estimé avant que l'utilisateur perçoive de la latence (environ 100ms). Ce qui peut être intéressant à connaitre avec des profilers injectant du code, faisant des arrêts pour consulter l'état du programme ou pour les profilers qui peuvent être réglés (durée et fréquence).

* (en) M. Jovic, A. Adamoli et M. Hauswirth, « Catch me if you can: performance bug detection in the wild », ACM SIGPLAN Notices - OOPSLA '11,‎ octobre 2011, p. 157-158 (ISBN 978-1-4503-0940-0, DOI 10.1145/2048066.2048081)

* (en) A. Adamoli, M. Jovic et M. Hauswirth, « LagAlyzer: A latency profile analysis and visualization tool », 2010 IEEE International Symposium on Performance Analysis of Systems & Software (ISPASS),‎ avril 2010, p. 157-158 (ISBN 978-1-4244-6024-3, DOI 10.1109/ISPASS.2010.5452080)

JPayrat (discuter) 23 janvier 2019 à 15:03 (CET)

Relecture sur la Fond partie "Analyse de teinte" (24.01.19)

Bonjour,

Voici mes observations de fond. De manière générale j'aurais aimer en apprendre un peu plus.

• mauvaise interprétation de la propagation de la teinte et/ou mauvaise référence : Tous les programmes qui sont dépendants de données teintées, sont alors à leur tour teintés22.
• comment cela fonctionne "l'analyse de teinte"? comment teint on les données? parler un peu plus de la propagation.
• Je ne vois pas bien la distinction entre les 2 cas d'utilisations possibles que vous évoquez, en considérant que les malwares sont de base des programmes. De plus la page de référence 27 semble erronée.
• ce passage aurait mériter plus d'éclaircissement, je n'arrive pas à trouver l'information dans les références indiqués.
• Suggestion: DTA=> http://bitblaze.cs.berkeley.edu/papers/dta%2B%2B-ndss11.pdf

Cdt, TV974 (discuter) 24 janvier 2019 à 12:28 (CET)TV974

Relecture sur la Fond partie "Débogage" (24.01.19)

Bonjour,

Voici les observation que j'ai pu faire sur le fond pour cette section:

• Suggestion: "Logic Programming Environments: Dynamic Program Analysis and Debugging" -> https://hal.inria.fr/inria-00074067/document, un travail de synthèse qui peut vous servir pour tout le sujet pas uniquement cette section.

(NB: relecture en cours) TV974 (discuter) 24 janvier 2019 à 14:46 (CET)TV974

Trouver des Bogues

Cette partie me laisse un peu confus et mériterait peut être un peu plus de précision.

• "Mais il existe aussi des fuzzer qui instrumentalisent le code à la compilation pour le parcourir plus efficacement et entrer dans toutes les branches disponible du programme33". => La référence est t'elle bien choisi? je ne retrouve pas ces informations.
• "C'est de cette manière que le fuzzer va sélectionner des valeurs propices pour entrer dans toutes les branches du programme." => à préciser ou à reformuler. Qu'entendez vous par là? le Fuzzer est un programme intélligent qui va parcourir le programme à tester, l'interpréter et choisir pour chaque variables les valeurs adéquats pour entrer dans chaque branches? Ou cherchez vous à illustrer l'execution symbolique énoncé dans le document?
• Vous semblez ne vous concentrer que sur "Une manière de pousser les bogues à apparaitre". Le fuzzing serait'elle la seule méthode en lien avec votre sujet pour trouver des bouges?
• Les tests "fuzzes" (test Blackbox) semblent être de nature en lien avec l'Analyse dynamique. Votre document de référence de P. Godefroid semble être tourné vers l'exécution symbolique (test WhiteBox) en lien avec l'Analyse statique. S'agit'il d'un hybride entre les 2 méthodes? (c'est ce que je comprends) Cela occupe près des 3/4 de votre sous rubrique. Est-ce représentatif des "fuzzer" dans le contexte de votre sujet?

TV974 (discuter) 1 février 2019 à 09:37 (CET)TV974

Bonjour !

Pour gagner du temps je ne vais répondre qu'a la dernière remarque, c'est moi qui était confus en lisant l'article et j'ai effectivement totalement mélangé les différents types d'analyse. J'ai réécrit cette partie en essayant d'être le plus clair possible cette fois.

Je pense qu'il est tout de même utile d'avoir une partie sur les comment trouver les bugs puisqu'elle permet d'accueillir les fuzzer et les tests (que nous n'avons pas eu le temps d'intégrer a l'article). J'ai également ajouté une source et un peu de matière pour que l'analyse statique prenne moins de place.

--Tamolegro (discuter) 13 février 2019 à 00:11 (CET)

Débogueur

Bonjour

• Il aurait été intéressant de mettre plus en avant comment les débuggeurs intègrent l'analyse dynamique (teinte ...).
• "Mais ces opérations ne sont pas évidentes étant donné que le code risque d'être optimisé par le compilateur." => vous évoquez un aspect intéressant. Comment le compilateur fait 'il pour optimiser? Le compilateur n'utiliserait 'il pas une méthode d'analyse dynamique?

TV974 (discuter) 4 février 2019 à 09:25 (CET)TV974

Relecture de fond : Analyse de la consommation de mémoire et Profileur statistique

Bonjour,

Vous avez deux exemples de code de profiler, ces deux sont écrits en langage Ruby. Y a t-il une raison de l'utilisation de se langage? Pour un programme Java est-ce le même code qui est utilisé ? Ou est-ce la simplicité qui permet une meilleure compréhension ?

Merci JPayrat (discuter) 31 janvier 2019 à 14:08 (CET)

Bonjour, la raison est en effet la simplicité du langage. Ça aurait été possible avec d'autres langage mais je pense que cela devrait plutôt apparaître sur une page dédiée au profilage.

--Tamolegro (discuter) 2 février 2019 à 13:44 (CET)

Relecture de fond : Analyse de la consommation de mémoire

Bonjour,

Dans ce chapitre vous parlez d'un « profileur qui regarde exactement le nombre de fois que chaque fonction a été appelée. » Dans le profiler statistique j'ai cru comprendre que l'on comptait également le nombre de fois que l'on passait dans une fonction.

Je comprend bien que dans le cas de l'analyse de la consommation de mémoire, les fonctions utilisant le plus de mémoire sont ciblés. Comment savons nous quelles fonctions consomment de la mémoire pour pouvoir les cibler?

Dans les deux codes en Ruby, on voit bien le comptage, mais pas le ciblage des fonctions concernées. Pourquoi dans le profilage statistique on n'a pas besoin d'instrumentaliser le code et pour l'analyse de la consommation de la mémoire oui ?

Merci

JPayrat (discuter) 31 janvier 2019 à 14:26 (CET)

Bonjour, étant donné que cela dépend de chaque langage je n'ai pas vraiment de réponse précise. Mais dans le cas du C par exemple, valgrind va cibler les malloc et les free.

Dans le cas du Ruby si je me souviens bien c'est une primitive du langage qui sert a l'allocation d'objet qui est ciblée. J'ai ajouté une source et l'exemple du C pour expliquer.

On a besoin d'instrumentaliser le code pour le profilage exact parce que c'est le code qui va notifier le profileur qu'il s'est passé quelque chose. Alors que dans le profilage statistique c'est le profileur qui arrête le code.

--Tamolegro (discuter) 12 février 2019 à 14:11 (CET)

Relecture de fond : Analyse énergétique

Dans le chapitre Analyse énergétique, vous n'abordez que très peu le profiling des instructions de code du programme en lui même.

« Le profilage énergétique, est une des solutions qui peut permettre de se rendre compte de la consommation d'un programme. Cela consiste à profiler le code d'une application tout en évaluant la consommation énergétique, afin d'associer une consommation à des instructions. »

Dès le début vous parlez de l'évaluation de la consommation énergétique liée à des instructions. Or par la suite vous ne parlez que de la consommation énergétique par rapport au matériel. Seule une ligne à la fin "Certaines technologies essaient même de fournir une estimation de la consommation énergétique pour une ligne de code donnée 22." évoque rapidement cette technique d'évaluation. Sur la source que vous citez le profileur « eLens » pour ce profiler la sortie est une visualisation qui montre la consommation d'énergie estimée du logiciel selon le chemin, la méthode, la ligne source et la granularité du programme entier. On peut trouver également le profileur « eProf » qui permet également le profiling énergétique. https://ieeexplore.ieee.org/document/6468359 .Nous avons développé eprof, un profileur qui associe la consommation d’énergie aux emplacements de code. Il attribue à la fois l’énergie consommée de manière synchrone dans la CPU et celle consommée de manière asynchrone dans les périphériques tels que les disques durs, les cartes réseau, etc. Eprof nécessite des modifications minimes du noyau ( des dizaines de lignes de code) et ne nécessite pas de matériel spécial pour les logiciels de profil énergétique. Par conséquent, eprof peut être largement utilisé pour aider les développeurs à prendre des décisions éclairées en matière d'énergie. Il serait peut être une idée de comparer les approches de ces deux profiler (ou d'autres encore) pour évoquer plus précisément leur technique de profiling.

JPayrat (discuter) 4 février 2019 à 09:40 (CET)

Bonjour,

Si je parle de la consommation énergétique par instruction et ensuite de la consommation énergétique par rapport au matériel, c'est parce qu'elles sont fondamentalement liées.

En effet le profiling par instruction permet d'avoir les plus petites unités de consommation (cela détermine le comportement du programme). Mais cette consommation doit être évaluée par un matériel donné (cela détermine l'environnement dans lequel va être exécuté le code). Par exemple un même programme ne consommera pas la même chose si il fonctionne sur un intel Pentium ou sur un intel i5.

Je pensais que le lien était évident mais je vais tenter de mettre une phrase qui élucide cette situation.

Deuxièmement je ne comprends pas pourquoi vous me relayait une de mes source (eprof) sans explication. Et par la phrase : «Nous avons développé eprof, [...]» je ne comprends pas si c'est une citation ou non et si oui, que signifie t-elle ici, sans contexte ? Sinon il me semble qu'eprof nécessite quand même des modèles énergétiques basés sur le hardware mis en cause afin de faire une analyse plutôt juste.

Sinon oui je pourrais comparer l'analyse hardware pure et l'analyse grâce au profilage énergétique.

NB : pour Eprof je n'arrive plus à retrouver l'information, mais il me semble que la consommation d'énergie est fournie en premier lieu par une API kernel vérifiant les composant et transmettant leur consommation.

Haydgoki (discuter) 12 février 2019 à 17:03 (CET)

Bonjour,

Je partage le constat précèdent.

• suggestion de lien possible: http://web.cs.ucla.edu/~palsberg/course/cs239/S04/papers/saputra02.pdf
• Vous évoquez que "L'analyse énergétique des programmes reste très compliquée à évaluer précisément." ainsi que "plusieurs facteurs". Le compilateur ou l'interpréteur ont ils un impact?
• Vous semblez dire qu'il est difficile d'analyser la consommation énergétique d'un programme notamment à cause de "composants tels que les GPS soient actifs ou non, ou que les antennes WIFI soient en transmission ou réception [...]". N'est'il pas possible de cibler l'analyse sur des éléments plus probants?

cdt,

TV974 (discuter) 4 février 2019 à 10:38 (CET)TV974

Bonjour,

tout d'abord merci pour le lien. Si l'on considère que l'analyse des programme se fait sur un programme qui n'est pas compilé alors oui le compilateur joue un rôle, puisqu'il pourrait compiler plus ou moins efficacement et donner plusieurs versions du programme différentes (Par exemple si le compilateur optimise plus ou moins la compilation).

Par contre sur un même programme binaire et sur une même machine, la consommation d'un programme reste globalement la même (mais cela peut changer un peu en fonction des processus lancés en parallèle, de la température de la pièce etc) .

Si un programme est interprété, cela reste le même cas qu'au compilateur, càd que ça dépendre de l'interpréteur, si il est plus ou moins performant.

L'exemple du GPS, de la puce wifi étaient utilisés pour mettre en valeur le fait qu'il y a beaucoup de composants mineurs qui rentrent en jeu. Le processeur, ou encore le disque dur, sont bien sûr, le plus souvent les éléments qui consomment le plus.

Cordialement,

Haydgoki (discuter) 12 février 2019 à 17:12 (CET)

Evaluation

Bonjour,

Evaluation de l'article réalisée.

Bonne journée,

Groumphy (discuter) 10 août 2020 à 08:10 (CEST)