985 bugs dans le noyau Linux

Posté par  (site web personnel) . Modéré par jerome.
Étiquettes :
0
17
déc.
2004
Noyau
La société Coverity a annoncé le 14 décembre que son produit SWAT (un analyseur statique de code très sophistiqué mais sous licence propriétaire) avait décelé 985 bugs sur un total de 5.7 millions de lignes de code dans le noyau Linux 2.6.9.
La majorité des bugs se trouve dans les modules des pilotes et seulement 1% dans le c½ur du noyau.
Le ratio est donc d'environ 0.17 bugs par millier de lignes ce qui, selon l'université Carnegie Mellon, est beaucoup moins que les logiciels classiques.
En effet il n'est pas rare d'observer, dans ces logiciels, un ratio de 20 à 30 bugs par millier de lignes ce qui se traduirait par un total compris entre 114.000 et 171.000 bugs sur un projet de la taille de Linux.

Voici un total récapitulatif des bugs considérés comme critiques du noyau :

* Défauts causant un crash système : 569
* Dépassement de tampon mémoire : 25
* Fuite mémoire : 33
* Problème de sécurité : 100 Une analyse un peu plus fouillée de cette annonce laisse toutefois entrevoir plusieurs zones d'ombres.
En premier lieu il semble que cet analyseur de code est juste une version commerciale (NdM : propriétaire) du logiciel "Stanford Checker" déjà connu et que la société Coverity est une start-up fondée pour vendre ce logiciel. Pour assurer sa promotion elle offre librement aux développeurs Linux le résultat de ses investigations. Il semble donc nécessaire de garder à l'esprit son souci de publicité.
Ensuite les ratios donnés par l'université Carnegie Mellon semblent étranges à beaucoup de commentateurs qui soulignent que les logiciels traditionnels ont plus probablement entre 1 et 5 bugs par millier de lignes de code (le chiffre de 2 pour Windows2000 a été avancé... sachant que ce système complet est bien plus gros qu'un simple noyau).
Enfin il faut bien voir que ce total de 985 bugs est un chiffre absolument minimum qui omet toutes les erreurs existantes dans le noyau mais passant, pour une raison ou pour une autre, à travers les mailles de SWAT.

Malgré tout cette annonce est bénéfique pour le projet Linux puisqu'elle va permettre de corriger des erreurs et qu'elle souligne la bonne qualité du noyau actuel.
Déclaration du kernel hacker Andrew Morton : This is a benefit to the Linux development community and we appreciate Coverity's efforts to help us improve the security and stability of Linux. We've already addressed the top priority bugs that Coverity has uncovered. It's a very useful system for high quality code."

Il est à noter que cette analyse n'est rendue possible que par la disponibilité des sources ce qui contraste singulièrement avec la situation de beaucoup d'autres systèmes dont la qualité est difficilement vérifiable (voilà un avantage réel et indiscutable de l'Open Source).
Enfin on peut évoquer le logiciel SPARSE qui est développé par Linus Torvalds lui-même afin de constituer une alternative libre à SWAT.

Aller plus loin

  • # je comprend pas trop...

    Posté par  (site web personnel, Mastodon) . Évalué à 9.

    Comment un logiciel peut-il détecter des bugs ?

    Pour moi, un bug est quand un programmeur a mal exprimé ce qu'il voulait faire dans le langage de programmation.

    Quand on programme, on part du principe que le langage fait exactement ce qu'on lui dit de faire.

    En gros, je ne comprend pas trop comment fonctionne ce genre de logiciel ni quels genre de bugs il peut trouver et surtout, pourquoi c'est pas intégré dans le compilateur directement.

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: je comprend pas trop...

      Posté par  . Évalué à 10.

      Je ne me souviens plus trop des détails, mais l'article de Linux Mag l'explique pas trop mal:
      http://www.linux-mag.com/2004-04/code_01.html(...)

    • [^] # Re: je comprend pas trop...

      Posté par  . Évalué à 10.

      Pour faire vite, tu as plusieurs types de bug. Tu as effectivement les bugs sémantiques et la sauf specifications formelles l'outil ne trouvera j'amais l'erreur. Tu regardes si 42 t'es envoyé alors que c'etait 422 ca marchera pas.

      Par contre tu peux facilement detecter des choses qui sont a coup sur des erreurs. Trivialement, ce que fait gcc, si tu utilises une variable non initialisé c'est un bug, une fuite mémoire ca peut se retrouver en analyse statique aussi.

      Évidement tu ne trouves pas tout et il faut vérifier ce que te sors l'outil. C'est l'étape plus évolué de ce que te propose gcc ou splint. Bien évidement c'est beaucoup simplifié mais tu trouveras sur la page de danwson engler quelques transparents interessant : http://www.stanford.edu/~engler/(...) . Ca tombe bien c'est le monsieur qui encadrait SWAT a stanford !

      > pourquoi c'est pas intégré dans le compilateur directement.

      Par ce qu'on peut faire du brouzouf avec et que personne n'a fait quelque chose de si évolué en libre ? :-)

      • [^] # Re: je comprend pas trop...

        Posté par  (site web personnel) . Évalué à 10.

        > pourquoi c'est pas intégré dans le compilateur directement.

        Par ce qu'on peut faire du brouzouf avec et que personne n'a fait quelque chose de si évolué en libre ? :-)

        Ou plutot parce que généralement, les outils d'analyse statique sont lents et pas pousse-boutons : il faut beaucoup de calculs pour obtenir des résultats (et donc beaucoup de temps) qui doivent être analysé par la suite. DE plus, il faut parfois rajouter des hypothèses lors de l'analyse pour obtenir un résultat utilsable. Evidemment, pas n'importe quelle hypothèses non plus, et c'est là encore un difficulté (par exemple, donner un invariant de boucle à l'outils qui ne sait généralement pas le trouver, mais qui est essentiel pour vérifier la terminaison de celles-ci).

        Bref, tout ça pour dire que tu ne peux pas forcément intégrer les outils d'analyse statique au compilo, mais ça n'empeche pas d'en avoir des libres.

        • [^] # Re: je comprend pas trop...

          Posté par  (site web personnel) . Évalué à 10.

          C'est aussi parce que ce que fait ce genre d'outil est indécidable dans le cas général. Donc, l'outil fait ce qu'il peut, mais aura toujours des faux positifs et/ou des faux négatifs. Or, le boulot d'un compilo, c'est de compiler les programmes corrects (éventuellement avec warnings) et de refuser les autres, et on aime bien que les règles qui disent comment le compilo choisi dans quel cas on est soient claires.

          • [^] # Re: je comprend pas trop...

            Posté par  . Évalué à 5.

            Donc, l'outil fait ce qu'il peut, mais aura toujours des faux positifs et/ou des faux négatifs.
            En effet, d'après http://www.linux-mag.com/2004-04/code_01.html(...)

            "Using the most recent advances in source code analysis, the types of bugs described in this article can be found in code bases the size of Linux with a false positive rate of less than 20%."

            En français :
            Le taux de faux positifs - c'est à dire des non-bugs détectés comme bugs par l'outil d'analyse de code - est inférieur à 20% avec les techniques récentes.

            On peut en déduire que 185 des 985 bugs n'en sont pas. Mais bien sûr ce sera compensé par tous les bugs non détectés...

            M

    • [^] # Re: je comprend pas trop...

      Posté par  . Évalué à 3.

      Pour le java, il y a FindBugs, il y a la liste des bugs détectés : http://findbugs.sourceforge.net/bugDescriptions.html(...)

      ca peut donner une idée. Il faut trier un peu trier le résultat, mais c'est deja pas mal.

    • [^] # Re: je comprend pas trop...

      Posté par  (site web personnel) . Évalué à 3.

      Comment un logiciel peut-il détecter des bugs ?

      Si tu veux un panel complet en quelques pages des techniques de vérification, tu peux lire le chapitre "Verification Techniques" du Guide d'utilisation d'Ada dans les systèmes de haute intégrité http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c029575_I(...)).zip

      En gros, je ne comprend pas trop [...] pourquoi c'est pas intégré dans le compilateur directement.

      Le compilateur ne peut pas faire de miracle : en amont, il y a la définition du langage utilisé. Si la définiton est imprécise, et la sémantique de bas niveau, la tâche devient virtuellement impossible pour les outils d'analyse statique.
      Alors à fortiori pour le compilateur dont ce n'est pas la vocation.

    • [^] # Re: je comprend pas trop...

      Posté par  . Évalué à -1.

      On peut dire qu'effectivement c'est plein de bug ... et alors ? comme tout. Le seul truc c'est que ca foncitonne pas comme tout :)

  • # Coverity

    Posté par  . Évalué à 8.

    Je me souviens avoir voulu essayer Coverity après avoir lu un article dans Linux Magazine (US). Leur produit à l'air extrêmement bien, mais pas vraiment facile à utiliser. On peut le tester gratuitement après enregistrement, mais l'outil d'analyse reste du coté de leur machines, il faut uploader un rapport. Pas forcément très convivial, surtout quand on en a pas vraiment l'utilité (mon cas).
    Du coup, je ne l'ai pas essayé... mais j'ai tout de même reçu un mail (qui semblait réellement écrit par un humain, c'est rare) pour me demander ma satisfaction. C'était plutôt gentil.

    Bref, ils ont l'air de faire du bon boulot :)

    • [^] # Re: Coverity

      Posté par  . Évalué à 6.

      (qui semblait réellement écrit par un humain, c'est rare)

      Ils se servent d'un « analyseur statique » de messages automatiques...

  • # Tout est relatif

    Posté par  . Évalué à 2.

    Je pense que tout est relatif, même quand on regarde le chiffre annoncé de 985 bugs, la perfection n'existe pas et heuresement !

    Je me pose une question, est-ce que il va y avoir une réaction de linus face à ce genre de rapport ?

    • [^] # Re: Tout est relatif

      Posté par  (site web personnel) . Évalué à 7.

      Le chiffre peut paraitre énorme, mais il faut savoir que 99% des bugs sont répartis dans des centaines de drivers et qu'on est loin d'en utiliser autant sur une seule machine.
      D'autre part certains bugs ont une probabilité d'apparition extrêmement faible voire nulle. D'autres peuvent avoir des conséquences négligeables.
      Si on estime selon l'article que pour 1000 lignes de code, Windows a 2 bugs et Linux 0.17, on peut en déduire que Linux est 10 fois plus stable que windows. Intéressant... et à retenir !

      • [^] # Re: Tout est relatif

        Posté par  . Évalué à 8.

        Si on estime selon l'article que pour 1000 lignes de code, Windows a 2 bugs et Linux 0.17, on peut en déduire que Linux est 10 fois plus stable que windows.

        Ce qui est une estimation ridicule...

        MS utilise ce genre d'outils depuis 2 ans maintenant sur le code des nouveaux OS. Il y a donc de fortes probabilites que cet outil la en aurait trouve bcp moins si il avait ete passe sur Windows vu qu'une passe du meme type a deja ete faite et les bugs corriges.

        Ca ne veut pas dire qu'il y a forcement moins de bugs dans l'un ou dans l'autre cependant, vu que ce type d'outil ne trouve que qqe categories de bugs.

        • [^] # Re: Tout est relatif

          Posté par  . Évalué à 10.

          MS utilise ce genre d'outils depuis 2 ans [...]


          D'un autre côté, comme personne n'utilise de Windows de moins de 2 ans ... :P

          • [^] # Re: Tout est relatif

            Posté par  . Évalué à 1.

            Windows Server 2003 & XP SP2

            Et XP SP2 ca fait bcp de monde...

            • [^] # Re: Tout est relatif

              Posté par  (site web personnel) . Évalué à 6.

              pas moi !
              et tout les utilisateurs lambda non plus ...
              2003 server est rare sur les postes prives, et le SP2, je connais plus de monde qui a eu des soucis avec que de gens qui le connaissent.

              • [^] # Re: Tout est relatif

                Posté par  . Évalué à 3.

                pas moi !
                t'es sur linuxfr, on s'attend pas à ce que la majorité pésente utilise intensivement les produits MS. C'est pas super représentatif du reste du monde.

                • [^] # Re: Tout est relatif

                  Posté par  (site web personnel) . Évalué à 9.

                  la majorité pésente utilise intensivement les produits MS

                  ça depend, moi j'adore leurs joysticks et leurs souris :-)

                  Axel

                  • [^] # Re: Tout est relatif

                    Posté par  . Évalué à 2.

                    et leurs claviers aussi sont très confortables :-)

                    • [^] # Re: Tout est relatif

                      Posté par  . Évalué à 4.

                      il ont une tres mauvaise resitance au café , je prefere logitech

                  • [^] # Re: Tout est relatif

                    Posté par  (site web personnel) . Évalué à 3.

                    J'approuve tout à fait, les souris femelles (sans boules) marquées Microsoft sont excellentes. Mais je me demande qui peut bien les fabriquer ?

                    • [^] # Re: Tout est relatif

                      Posté par  . Évalué à 3.

                      Ils sous-traitent à Flextronics, comme pour la Xbox et sûrement tout le reste du matériel Microsoft.

                    • [^] # Re: Tout est relatif

                      Posté par  . Évalué à 1.

                      Un certain nombre de souris sont sous-traité chez ST.
                      Ceci dis, j'ai deja dans mon entourage pas moins de 7 souris microsoft qui sont tombées en panne a plus ou moins longt terme.
                      C'est la seule marque chez qui jai constaté des defaillances, meme en regardant du coté des génériques.
                      Donc si je dois choisir entre une Microsoft et une logitheque, mon coeur va pour logitech.
                      Enfin, je sais pas si certains ont essayer d'ouvrir une souris microsoft, mais à moins de casser le boitier, c'est quasiment impossible.
                      ( deux visses sur ma logitech ).

                      • [^] # Re: Tout est relatif

                        Posté par  . Évalué à 1.

                        Tu ouvres souvent une souris optique ?

                        • [^] # Re: Tout est relatif

                          Posté par  . Évalué à 1.

                          Lorsque le fil de ta souris a un mauvais contact ( rare, mais j'ai deja vus ça deux fois avec les souris m$), ça peut être pratique d'ouvrir ta souris pour faire la reparation toi meme.

                          En ce qui me concerne, j'ai voulu modifier ma souris optique sans fils logitech car je la trouvais lourde et couteuse en batterie.

                          Je lui ai donc ouvert le ventre, puis j'ai remplacé les piles par un gros condensateur ( 7 Farad sous 3v ).
                          Le condensateur se recharge presque instatanement lorsque je passe ma souris sur le tapis.
                          celui-ci est recouvert de deux feuille d'alluminium, elle meme relier à une petite alimentation secteur.

              • [^] # Re: Tout est relatif

                Posté par  . Évalué à 1.

                Chacun son truc, moi je regardes les stats et elles sont claires, ton cas particulier lui c'est autre chose et il est loin de refleter la realite.

            • [^] # Re: Tout est relatif

              Posté par  . Évalué à 2.

              Et XP SP2 ca fait bcp de monde...

              Pas tant que ça, beaucoup reviennent au sp1. À tort ou à raison, mais c' est le cas.

              • [^] # Re: Tout est relatif

                Posté par  . Évalué à 0.

                Beaucoup ca reste a voir, il y en a certainement, de la a ce que ce soit la majorite il y a un enorme pas que je ne franchis pas pour la simple raison que les chiffres de Windows Update montrent que ce n'est pas le cas, le SP2 s'est tres vite repandu.

                • [^] # Re: Tout est relatif

                  Posté par  (site web personnel) . Évalué à 1.

                  Je ne sais pas lequel de vous deux a raison mais le fait est que le monsieur a dit que les gens "reviennent" au sp1. Ce qui signifie(rait) qu'ils installent puis désinstallent le sp2. Auquel cas les chiffres de windows update ne veulent plus rien dire... (à moins que windows update ne soit aussi prévenu quand tu désinstalles un logiciel - ils iraient jusque là ?)

                  • [^] # Re: Tout est relatif

                    Posté par  . Évalué à 1.

                    WindowsUpdate donne les updates systemes, et vu qu'il doit savoir quel patch te donner il sait quel niveau de service pack tu as bien evidemment. Les chiffres sont la, bcp de gens sont sur le SP2. Si ils etaient repasses sur le SP1 ils apparaitraient dans la colonne SP1.

                    • [^] # Re: Tout est relatif

                      Posté par  (site web personnel) . Évalué à 2.

                      Je ne suis pas trop d'accord avec le raisonnement, vu que les gens qui désinitallent SP2 sont plutôt du genre a ne plus remettre les pieds sur WindowsUpdate, mais pour la conclusion, oui, puisque d'autres stats le montrent :

                      http://www.xitimonitor.com/etudes/equipement0.asp(...)

                      • [^] # Re: Tout est relatif

                        Posté par  . Évalué à 2.

                        Ben justement, ce qui ne vont pas sur WindowsUpdate ne sont pas comptabilises... WindowsUpdate connait le nombre de machines avec SP2 qui le contactent chaque mois, et MS connait grossierement le nombre de XP dans la nature --> proportion

                        • [^] # Re: Tout est relatif

                          Posté par  (site web personnel) . Évalué à 2.

                          Donc la question est pluttot de savoir si l'ensemble des encore connectés à WindowsUpdate est repréentatif statistiquement des non connectés. Dans ce cas, bcp seraient passés au SP2.

                          Cela dit je connais effectivement pas mal de monde qui sont passés au SP2 et qui ont rétroinstallé en virant WindowsUpdate ("ça me pose plus de pb qu'autre chose" me dit-on en général)

                          Sans vouloir lancer le troll. Le seul avantage que je connais à Linux par rapport à win, c'est que sous linux la mémoire est beaucoup mieux gérée, et que windows laisse une impression à l'utilisation de système baclé.

                          Tiens en ce moment, je suis sous le xp d'un copain, ben qd j'ouvre explorer sur un simple répertoire contenant des archives et des vidéo, explorer fige, je suis obligé de le redémarer. J'accède au répertoire en tappant son chemin dans la barre d'adresse, ça marche !!

                          Tu vois, pBpG, windows, c'est toujours comme ça. J'en gère 35 dans ma boite et je n'ai que des problèmes de ce style.
                          Windows, c'est baclé, c'est pas fignolé comme système.

                          Malgré cela il a de grandes qualités et reste, sur le papier une vrai merveille que linux aura du mal à atteindre. Le problème c'est que le code ne réalise pas tout ce que Bilou a voulu que windows fasse...

                          Bon, je suis légèrement HS

                          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                        • [^] # Re: Tout est relatif

                          Posté par  (site web personnel) . Évalué à 3.

                          Donc un gusse qui a installé un sp2, puis devant les problèmes à réinstaller windows et désactivé windows update pour rester avec le sp1, est compté comme ayant installer un sp2 ?

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

                          • [^] # Re: Tout est relatif

                            Posté par  . Évalué à 1.

                            Ben si il passe sur WU quand il a SP2 il est compte pour le SP2, si le mois suivant il passe pas car il est repasse en sp1 et desactive WU il est pas compte, etc...

                            C'est des statistiques a intervalles reguliers, ils font pas une statistique un jour donne et s'arretent la bien evidemment.

        • [^] # Re: Tout est relatif

          Posté par  . Évalué à 6.

          ... Et le code de windows étant fermé on ne poura de toute façon pas vérifier ...

        • [^] # Re: Tout est relatif

          Posté par  . Évalué à 0.

          "MS utilise ce genre d'outils depuis 2 ans maintenant sur le code des nouveaux OS"
          euh franchement j'en doute....... ça te dit quelque chose ms03-039 ?.
          ou peut être que tout est relatif..

          • [^] # Re: Tout est relatif

            Posté par  . Évalué à 1.

            Oui ca me dit qqe chose, mais il faut bien comprendre que ces softs ne trouvent pas tous les bugs.

      • [^] # Re: Tout est relatif

        Posté par  . Évalué à 9.

        Si on estime selon l'article que pour 1000 lignes de code, Windows a 2 bugs et Linux 0.17, on peut en déduire que Linux est 10 fois plus stable que windows. Intéressant... et à retenir !

        bof pas vraiment non. l'utilisateur lambda (99% des gens faut il le rappeler?) il s'en fout que ce soit linux ou kde qui plante, pour lui "linux plante". Bref la stabilite de linux c est surement tres bien, mais ce n'est interessant que si les appli utilisateurs sont elles aussi stables. De plus les problemes de windows sont souvent du a ce qui se trouve entre la chaise et le clavier. Quand je vois des gens qui se loge en root sous KDE, je suis dubitatif vis a vis de la securite du systeme.
        Enfin windows a prouve que les utilisateurs preferaient les fonctionnalites et la simplicite(?) a la stabilite et la securite.
        et puis accessoirement, mon XP ne plante jamais (mon linux non plus :) ).

        --
        pouet

        • [^] # Re: Tout est relatif

          Posté par  . Évalué à 1.

          "Quand je vois des gens qui se loge en root sous KDE, je suis dubitatif vis a vis de la securite du systeme."

          Je reste, en ce qui me concerne, dubitatif sur ce genre d'assertion "gratuite"!

          Ce qui est à mettre en cause là, c'est l'éducation de l'utilisateur plutôt que la sécurité système.

          • [^] # Re: Tout est relatif

            Posté par  (site web personnel) . Évalué à 3.

            De la meme façon que les gens qui se connectent sur MS\Windows XP en administrateur, ou sous KDE, GNOME en root, il y aura de plus en plus de virus sous GNU/Linux.
            Tant mieux, les migrations n'en seront que plus douces pour les utilisateurs venant de MS\Windows.

    • [^] # Re: Tout est relatif

      Posté par  . Évalué à 7.

      a perfection n'existe pas et heureusement !

      Qu'est-ce qu'on peut lire comme bêtises parfois.

      • [^] # Re: Tout est relatif

        Posté par  . Évalué à 4.

        Non franchement, c'est pas ridicule ! Mais ça tient plutot de discussions philosophiques sur l'existence et tout ça ;-)
        maintenant, on la cherche cette perfection, c'est ça qui compte....

        • [^] # Re: Tout est relatif

          Posté par  . Évalué à 7.

          Oui, ne c'est pas ridicule, quelque chose de parfait n'a plus besoin d'évoluer. La déviance et l'erreur sont les sources de l'évolution nous apprennent les biologistes, les philosophes, les systémiciens ... bref tous ceux qui s'intéressent à la vie et à son évolution.

      • [^] # Re: Tout est relatif

        Posté par  . Évalué à 5.

        Non ce n'est pas une bétise du tout :
        quel serait l'avenir d'une communauté (de LL par exemple) ou tout serait parfait ?
        quoi faire de plus ? rien puisque tout est parfait , tout ce que tu peux faire en plus ne peux QU'ajouter de l'imparfait au passé déja composé parfait, le plus que parfait n'étant pas possible, quel futur dans tout cela ?
        C'est vrai c'est plus philosophique que informatique

        • [^] # Re: Tout est relatif

          Posté par  (Mastodon) . Évalué à 6.

          Il y a quand même la place pour pas mal de choses entre le "rien n'est parfait" et le "tout est parfait", non ? :)

          • [^] # Re: Tout est relatif

            Posté par  . Évalué à 1.

            la perfection est un état que nous tentons de rejoindre asymptotiquement.
            Je n'ai malheureusement pas connaissance autour de moi de quelquechose de parfais (ok je ne dis pas heureusement :-)

            • [^] # Re: Tout est relatif

              Posté par  . Évalué à 4.

              "Ne crains pas la perfection, tu ,ne l'atteindra jamais"
              Salvador Dali
              (dans ses Conseils pour devenir peintre, je crois)

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Tout est relatif

          Posté par  . Évalué à 6.

          en fait, c'est plus l'erreur orthographique du mot heureusement qui est la bétise (l'auteur original avait écrit "heuresement")... pas la référence philosophique à la perfection.

          moi aussi je suis tombé dans le panneau au début :)
          mais bon, un score de 9 (au moment où j'écris) pour une simple correction de français, c'est un peu énorme... à mon avis tout le monde à du pensé que c'était un commentaire philosophique

  • # 13 % de « code mort »

    Posté par  . Évalué à 5.

    Euh, est-ce que les bogues trouvés dans le code mort (dead code) sont comptés ?

    Si c'est le cas, Linux vient de perdre d'un coup environ 13 % de bogues :oP

    • [^] # Re: 13 % de « code mort »

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      il y'a eu un gros nettoyage ?

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: 13 % de « code mort »

        Posté par  . Évalué à 5.

        Ben par définition le code mort n'est jamais exécuté, donc c'est autant de bugs qui ne poseront jamais de problème.

        • [^] # Re: 13 % de « code mort »

          Posté par  . Évalué à 3.

          Comment est-on sûr qu'il ne sera jamais exécuté ?
          En théorie, il ne sera pas exécuté http://www.linuxfr-france.org.invalid/prj/jargonf/C/code_mort.html(...)
          Mais est-ce qu'un pointeur mal ficelé ne peut pas aller le réveiller ?
          Dans mon job, une appli avait dérapé et les développeurs avaient expliqué ce dérapage à cause de la présence de code mort.

          • [^] # Re: 13 % de « code mort »

            Posté par  . Évalué à 3.

            est-ce qu'un pointeur mal ficelé ne peut pas aller le réveiller ?


            Si ton code est mort, il est mort. Si un pointeur est mal ficelé, ça a faire du dégat, code mort ou pas.

            • [^] # Re: 13 % de « code mort »

              Posté par  . Évalué à 6.

              Si ton code est mort, il est mort. 
              Ben non, justement... Si ton code est mort, cela signifie que tu estimes qu'il
 ne sera jamais exécuté, pas qu'il ne le sera jamais dans l'absolu. 
Considère l'exemple suivant : 

int main(int argc, char** argv){
   if((argc==1)||(argc>=3)) {
      fprintf(stderr,"usage : truc [fichier]\n");
      exit(1);
      fprintf(stderr,"Code mort 1\n");
   }
   else if(argc==2){
      fprintf(stdout,"Truc a été bien appelé!\n");
      exit(0);
      fprintf(stderr,"Code mort 2\n");
   }
   else{
      fprintf(stderr,"Code mort 3\n");
   }
}

Il y a trois morceaux de code mort, dont on peut raisonnablement espérer 
qu'ils ne seront jamais exécutés. Malheureusement, ce n'est pas vraiment le
 cas : 
-Si on se lie avec des bibliothèques non-standards, exit() peut être bogué et 
revenir;
-La troisième portion n'est de toutes façons pas morte, puisqu'on peut avoir 
argc==0 (même si c'est assez rare).

Donc le programmeur a inclus du code "mort", pour détecter des problèmes,
 et ce code peut effectivement être exécuté dans certains cas.

              • [^] # Re: 13 % de « code mort »

                Posté par  . Évalué à 3.

                Ce n'est pas vraiment ca du "code mort" ... comme tu l'expliques on ne peut pas se baser sur les actions présumées d'une fonction ...
                Voici un exemple de code mort:

                {
                int i=0;
                if(i>10)
                { /* voici du code mort car i ne sera jamais > à 10 ici */
                ma_fontion();
                }
                }

                Pour ceux qui pensent au multithread, noter que 'i' n'est pas static ou global ...

                • [^] # Re: 13 % de « code mort »

                  Posté par  . Évalué à 3.

                  Ben, ton exemple correspond à ma troisième erreur... Dans laquelle le programmeur CROYAIT que argc était toujours supérieur ou égal à 1, mais ou il s'est trompé. Sinon, quel serait l'intérêt du code mort, à ton avis?

                  (Effectivement, dans ton exemple, le code mort ne sert à rien, mais, dans la réalité, il est justement assez difficile de garantir avec une totale certitude une affirmation du genre i ne sera jamais > à 10 ici).

                  • [^] # Re: 13 % de « code mort »

                    Posté par  (site web personnel) . Évalué à 3.

                    Je veux voir un exemple où argc==0.

                    • [^] # Re: 13 % de « code mort »

                      Posté par  . Évalué à 3.

                      execvp("mon_prog",NULL) est autorisé sur certains systèmes, d'après mes souvenirs.

                      • [^] # Re: 13 % de « code mort »

                        Posté par  (site web personnel) . Évalué à 4.

                        En effet, ça marche. Mea culpa, je n'aurais pas cru! 
                        $ cat testargc.c
int main(int argc, char *argv[])
{
        printf("argc = %d\n", argc);
        return 0;
}
$ cat testexec.c
#include <unistd.h>
 
int main (int argc, char *argv[])
{
        execvp("./testargc", NULL);
        return 0;
}
$ gcc -o testargc testargc.c; gcc -o testexec testexec.c
$ ./testargc
argc = 1
$ ./testexec
argc = 0

                        • [^] # Re: 13 % de « code mort »

                          Posté par  (site web personnel) . Évalué à 3.

                          D'après http://www-ccs.ucsd.edu/c/lib_over.html#program%20startup(...)
                          argc is a value (always greater than zero)
                          Donc je pense qu'on peut dire que c'est un bug (ça le fait aussi avec gcc --std=c89 mais c'est plutôt un problème de bibliothèque que de compilateur je pense).

                          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                          • [^] # Re: 13 % de « code mort »

                            Posté par  . Évalué à 5.

                            Depuis quand une page sortie au hasard d'internet permet de dire que c'est un bug ?

                            Chez moi POSIX dit ca :

                            =======
                            Early proposals required that the value of argc passed to main() be "one or greater". This was driven by the same requirement in drafts of the ISO C standard. In fact, historical implementations have passed a value of zero when no arguments are supplied to the caller of the exec functions. This requirement was removed from the ISO C standard and subsequently removed from this volume of IEEE Std 1003.1-2001 as well. The wording, in particular the use of the word should, requires a Strictly Conforming POSIX Application to pass at least one argument to the exec function, thus guaranteeing that argc be one or greater when invoked by such an application. In fact, this is good practice, since many existing applications reference argv[0] without first checking the value of argc.
                            =========

                            On notera le should !

                            Pour la norme C je te laisse chercher tout seul les outils pour lire du ps dans gnome sont tellement pratique qu'en 2004 y'a toujours pas la fonction "recherche"

                            • [^] # Re: 13 % de « code mort »

                              Posté par  . Évalué à 1.

                              les outils pour lire du ps dans gnome sont tellement pratique qu'en 2004 y'a toujours pas la fonction "recherche"
                              ps2ascii | grep

                            • [^] # Re: 13 % de « code mort »

                              Posté par  (site web personnel) . Évalué à 3.

                              Et donc un commentaire venant de toi est censé être plus crédible qu'un page "au hasard" :)
                              Enfin, j'ai retrouvé ce que tu cites ici (ça effectivement c'est plus crédible): http://www.opengroup.org/onlinepubs/009695399/functions/exec.html(...)

                              Bon ba faudra que je dise à mon prof de C que les références qu'il nous a donné sont foireuses.

                              Sinon apparement ya un PDF de C99 là http://www.nirvani.net/docs/ansi_c.pdf(...) (trouvé sur Wikipedia) qui dit la même chose: (page 26)
                              - The value of argc shall be nonnegative.
                              Moi on m'a toujours dit que zéro est à la fois négatif et positif mais bon deux lignes plus loin:
                              - If the value of argc is greater than zero[...]
                              Ce qui suppose que argc peut valoir zéro.

                              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                              • [^] # Re: 13 % de « code mort »

                                Posté par  . Évalué à 2.

                                > Et donc un commentaire venant de toi est censé être plus crédible qu'un page "au hasard" :)

                                Bien sur que non ! C'est simplement que c'est la norme :-)
                                Effectivement j'ai oublié de donner le lien je m'en excuse.

                                L'avantage c'est que dans la norme tu peux dire n'importe quoi tu es la norme !

                                > Bon ba faudra que je dise à mon prof de C que les références qu'il nous a donné sont foireuses.

                                Il me semble deja avoir vu passer ce lien et qu'il est pas mal. Ca ne l'empeche pas de dire au moins une connerie et si c'est la seule il est tres largement au dessus de la moyenne :-)

                              • [^] # Re: 13 % de « code mort »

                                Posté par  . Évalué à 3.

                                En Anglais, nonnegative ça veut dire >= 0, negative < 0, nonpositive <= 0, positive > 0.

                • [^] # Re: 13 % de « code mort »

                  Posté par  . Évalué à 1.

                  Malgrés que cela puisse paraitre un peu capilotracté, il existe les single event (une particule lourde qui passe par la) et pour la valeur du registre change. Dans des environnements radioactifs, spacial ou haute altitude on peut s'amuser à les détecter avec ce genre de code.

              • [^] # Re: 13 % de « code mort »

                Posté par  (site web personnel) . Évalué à 5.

                si argc peut être 0, alors ton "code mort 3" n'en est pas.

                du code mort, c'est lorsque la sémantique du langage fait que le code ne peut pas être exécuté, quelles que soient les données : si ton premier test était argc <=1, si tu mets du code après un return (et que le compilo l'autorise). et effectivement compter sur exit() n'est pas bon.

                • [^] # Re: 13 % de « code mort »

                  Posté par  . Évalué à 0.

                  Heu, à priori, c'est pas ça la définition du code mort...

                  Ca, c'est une définition trop forte. Pour moi, le code mort, c'est un code dont le programmeur à la conviction qu'il ne sera jamais exécuté, mais qu'il met quand même, pour éviter les mauvaises surprises.

                  C'est très employé dans les applications critiques, pour justement se garantir contre les fautes de programmation (le pilote de ligne a rarement vi, gdb et gcc sous la main pour déboguer en vol le pilote automatique en cas de pépin).

                  (Cela dit, c'est vrai que le nom n'est pas très bon : il vaudrait mieux l'appeler code pseudo-mort, puisque l'on n'est pas absolument sûr qu'il l'est. Je pense que c'est ce problème de dénomination qui gêne.)

                  • [^] # Re: 13 % de « code mort »

                    Posté par  . Évalué à 4.

                    moi qui pensait que le code mort concernait aussi (comprendre surtout) les instructions que le développeur insère dans le but qu'il soit exécuté, mais à l'analyse du programme ont s'apperçoit que ce ne
                    sera pas le cas.
                    Jamais exécuté ? on ne parle pas de probabilité, càd code mort = code 0% de possibilité d'éxécution ou il existe quelques possibilitées pour que cela arrive sachant que les conditions liées à des enchainements en run-time : l'utilisateur à créé une circonstance, un état "buggé" par la suite de ses actions.
                    Je doute que l'analyseur de code puisse prendre la totalité de ces probabilités.

                    PS : et pas 13% de bug en plus du au code mort, sinon ça ferait 100% de bug dedans, je doute que les développeurs du kernel soient si mauvais

                    • [^] # Re: 13 % de « code mort »

                      Posté par  . Évalué à 2.

                      >amais exécuté ? on ne parle pas de probabilité, càd code mort = code 0% de possibilité
                      > d'éxécution ou il existe quelques possibilitées pour que cela arrive sachant que les conditions
                      > liées à des enchainements en run-time

                      C'est rigolo, parce qu'un évènement de probabilité 0 n'est pas forcément impossible ;)

                      • [^] # Re: 13 % de « code mort »

                        Posté par  . Évalué à 3.

                        Ca dépend de la définition de la probabilité que tu utilises (à savoir : fréquentiste ou bayesienne ?).

                        Un fréquentiste te diras qu'un événement de probabilité 0, aura une fréquence d'apparition de 0 sur 100 tirages (ensuite il y a le problème de savoir l'erreur sur cette affirmation).

                        Un Bayésien te donne juste sa confiance en le fait que tel ou tel évènement se produise.

                        Donc à mon avis pour ce genre d'évènement (un muon cosmique qui traverse un transistor, communique la bonne énergie au bon electron pour le faire sauter de niveau d'énergie au "bon" moment) qui est somme toute assez rare (à l'abri de notre bonne vieille atmosphère, et assez loin de toute source de radiations), il vaut mieux accompagner toute probabilité d'une bonne dose de "niveau de confiance" que l'on veut bien lui associer.

                        Voilà, c'était juste la petite minute de quadri-pilo-sectomie...

                        • [^] # Re: 13 % de « code mort »

                          Posté par  . Évalué à 1.

                          Comme disait mon prof de math, tout arrivera, y compris le jour où la craie monte au plafond.

                          • [^] # Re: 13 % de « code mort »

                            Posté par  . Évalué à 2.

                            Et comme tout bon prof de maths il se plaçait dans un cadre mathématique solide et consistent et pouvait dire que si on a à notre disposition assez de temps pour regarder si la craie monte au plafond, un temps au minimum infini, alors on pourra voir la craie monter au plafond.

                            Mais pour cela, il faut quelqu'un qui ait du temps (un fonctionnaire ?;), et il faut un temps infini.
                            Pour la première hypothèse, on peut trouver quelqu'un (si c'est bien payé).
                            La deuxième est nettement plus hasardeuse : qui peut m'affirmer/me-démontrer dans la salle que l'univers est éternel ? :P

                        • [^] # Re: 13 % de « code mort »

                          Posté par  . Évalué à 1.

                          Moi je dirais surtout que ca dépend de la mesure de probabilité. Enfin bref on peut trouver des ensembles non vide de mesure nulle (un point sur la droite des Réelles, par rapport à la mesure de Lebesgue par exemple). Donc voila l'evement faire une coupe sur un ruban tout pile sur un point donné doit bien avoir une probabilité nulle, mais il se peut quand même qu'il se produise. (d'accord c'est vraiment pas de chance)

                  • [^] # Re: 13 % de « code mort »

                    Posté par  (site web personnel) . Évalué à 3.

                    ah le code mort de surveillance d'une variable dont on se fout qui fait partir l'équipement en autotest en plein vole...

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

                    • [^] # Re: 13 % de « code mort »

                      Posté par  . Évalué à 9.

                      Le code mort, c'est du code qui était vivant mais qui ne l'est plus. Typiquement, tu écris une fonction qui n'est appelée qu'à un endroit de ton code, puis tu changes le code l'appelant par une version n'utilisant plus ladite fonction. Comme tu es pressé et que tu as plein d'autres modifs à faire, et qu'en plus tu te dis que cette fonction pourra te re-servir un jour, tu ne vires pas son code de tes sources, bien qu'il ne soit plus appelé par personne.

                      • [^] # Re: 13 % de « code mort »

                        Posté par  (site web personnel) . Évalué à 1.

                        Au vue des différences interprétations, du code mort, c'est du code qui ne sert à rien dans un cas d'utilisation """normal""".

                        Le cas du code mort en question était le traitement d'une variable à un endroit mais qui ne servait à un rien ensuite. Par contre, l'exception derrière a été fatal...

                        (je parle d'un cas très connu en fait...)

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

                        • [^] # Re: 13 % de « code mort »

                          Posté par  . Évalué à 3.

                          Selon ta définition, tout le code de traitement d'erreurs serait du code mort...
                          (je parle d'un cas très connu en fait...)

                          Ariane ? (pas celle du club Dorothée)

                  • [^] # Re: 13 % de « code mort »

                    Posté par  (site web personnel) . Évalué à 5.

                    Pour moi le code mort est du code ne pouvant pas être executé et que le compilateur doit essayer au maximum de supprimer.
                    Après tu as le code mort repérable par le compilo (if(0) par exemple ou if(3<2) après propagation des constantes), celui qui pourrait être repéré par le compilo mais moyennant des analyses trop complexes, et tu as le code mort parce que certaines valeurs de parametres exterieurs ne pourront/devront jamais arriver (et ca la plupart des languages ne peuvent pas l'exprimer proprement). D'ailleurs je me demande si gcc considère le bloc mort dans:
                    assert(i>5);
                    
if(i<3){...}

                  • [^] # Re: 13 % de « code mort »

                    Posté par  . Évalué à 3.

                    >Heu, à priori, c'est pas ça la définition du code mort...

                    Ca, c'est une définition trop forte. Pour moi, le code mort, c'est un code dont le programmeur à la conviction qu'il ne sera jamais exécuté, mais qu'il met quand même, pour éviter les mauvaises surprises.

                    C'est original.

                    J'explique plutot le "code mort" par des raisons historiques. Du code qui servait au moment de son écriture, mais suite à l'évolution du code, il ne sert plus. Certe il y a les branches conditionelles dont une condition n'est plus jamais vérifiées (*), mais il a surtout les fonctions qui ne sont plus jamais appellées ou dont l'effet est ignoré. C'est du code *mort*.

                    Et effectivement il se peut qu'il y ai des bugs parmis ces lignes.

                    (*) que les amateurs de particules radioactives qui changent les valeurs du registre juste au moment du test, qui ne tentent pas de démontrer un cas général par un cas ultra particulier lèvent la main !

                    Cela dit, c'est vrai que le nom n'est pas très bon

                    Peut-être que c'est ta définition de "code mort" qui n'est pas très bonne... Il est évidant qu'elle ne colle pas avec l'expression. En tout cas, moi c'est la première fois que j'entends parler de code mort dans ce sens là. Une référence ?

                  • [^] # Re: 13 % de « code mort »

                    Posté par  (site web personnel) . Évalué à 4.


                    Ca, c'est une définition trop forte. Pour moi, le code mort, c'est un code dont le programmeur à la conviction qu'il ne sera jamais exécuté, mais qu'il met quand même, pour éviter les mauvaises surprises.


                    La DO178 (qui est utilisée pour l'avionique critique), fait une distinction entre deactivated code et deadcode. Ce dont tu parles entre dans la catégorie deactivated.

                    Par exemple un traitement d'exception que l'on mets au cas ou, ou un if dépendant d'un booléen de configuration dont une des branches ne sera jamais exécuté dans cette configuration là. Le deactivated code n'est volontairement pas exécuté.

                    Le dead code n'est pas non plus exécuté, mais c'est par erreur, souvent détectable par les outils d'analyse statique, du genre :

                    
if i > 10 then
                    
   if i < 3 then
                    
      -- dead code
                    
   end if;
                    
end if;

    • [^] # Re: 13 % de « code mort »

      Posté par  (site web personnel) . Évalué à 4.

      13%, c'est 13% des bugs trouvés, pas 13% du code ...

      • [^] # Re: 13 % de « code mort »

        Posté par  . Évalué à 3.

        Exact. 50 réponses dans le fil et personne ne l'avait encore relevé. Comme quoi avec des chiffres, on peut dire ce qu'on veut (surtout quand ça fait plaisir ;o).

        Par contre, on ne sait pas (d'après ces seules statistiques) si les bogues trouvés dans le code mort sont comptés ou pas. S'ils ne sont pas comptés : tant pis. S'ils le sont : en supprimant le code mort, on les supprime aussi (mais on a pas les chiffres pour l'estimer).

  • # Seulement un sous-ensemble de tous les bugs

    Posté par  (site web personnel) . Évalué à 7.

    Cet outil ne peut trouver qu'un certain sous ensemble des bugs présents dans le code.

    Il a déjà été appliqué de nombreuses fois au code de linux, et les bugs présents dans ce sous-ensemble ont été progressivement éliminés. Il est normal qu'il en reste très peu.

    Donc cette statistique ne donne en fait que peu d'informations puisqu'un nombre inconnu de bugs indétectables par le programme subsistent.

    • [^] # Re: Seulement un sous-ensemble de tous les bugs

      Posté par  (site web personnel) . Évalué à 4.

      Cet outil ne peut trouver qu'un certain sous ensemble des bugs présents dans le code.


      C'est bien pour cela que j'ai pris la peine d'écrire dans la news :

      "Enfin il faut bien voir que ce total de 985 bugs est un chiffre absolument minimum qui omet toutes les erreurs existantes dans le noyau mais passant, pour une raison ou pour une autre, à travers les mailles de SWAT".

  • # Oui, mais où ?

    Posté par  . Évalué à 3.

    J'ai visité les stats. Quelqu'un a-t-il trouvé comment accéder aux détails de ces bugs ? Ligne de code, opération concernée, ... ?

    Merci

    CdM

    • [^] # Re: Oui, mais où ?

      Posté par  (site web personnel) . Évalué à 4.

      il faut contacter directement la société Coverity pour qu'il te refile le détail des bugs.
      les devs du noyau l'on fait et on reçu l'analyse ce qui permet de corriger les erreurs.

      • [^] # Re: Oui, mais où ?

        Posté par  . Évalué à 2.

        il faut contacter directement la société Coverity pour qu'il te refile le détail des bugs.
        les devs du noyau l'on fait et on reçu l'analyse ce qui permet de corriger les erreurs.

        Est-ce que ça veut dire que après correction, plus aucun bug (ou presque) ne sera détecté avec ce soft ?

        Dans ce cas-là, il serait intéressant d'analyser le code de n'importe quel logiciel avec plusieurs détecteurs de bug et on n'obtiendrait un programme assez propre non ?

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Polyspace

    Posté par  . Évalué à 2.

    Nous, au boulot, on utilise un outil apparement similaire : Polyspace de la société Polyspace Technologies.
    http://www.polyspace.com/(...)
    Je ne l'ai jamais utilisé personellement.
    Est-ce que certains d'entre vous connaissent, et savez-vous si il a été passé sur le noyau ?

    • [^] # Re: Polyspace

      Posté par  . Évalué à 3.

      Je ne pense pas qu'il ait jamais été utilisé sur le noyau Linux, ceci dit le Verifier de Polyspace est un bon produit, quand on sait interpréter ses résultats. Il faut pas mal d'interventions manuelles pour obtenir un résultat satisfaisant, la réponse favorite étant "orange" (le code est coloré en fonction des erreurs détectées), c'est à dire "peut-être".

  • # SWAT exempté?

    Posté par  . Évalué à 4.

    Et le dit programme "SWAT", il en est à combien de bug? :)

    • [^] # Re: SWAT exempté?

      Posté par  . Évalué à 5.

      Zéro. D'après le très éprouvé logiciel SWAT, s'entend ;-).

    • [^] # d'ailleurs...

      Posté par  . Évalué à 10.


      ChangeSet@1.1907, 2004-09-02 17:00:19-07:00, torvalds@ppc970.osdl.org
      The coverity source checker is wrong. Revert some of the "leak fixes".

      Thanks to Davem for noticing. We probably should _not_ trust the
      coverity reports that much.

      Cset exclude: davej@redhat.com[torvalds]|ChangeSet|20040902213928|62770
      Cset exclude: davej@redhat.com[torvalds]|ChangeSet|20040902213829|63705

    • [^] # Re: SWAT exempté?

      Posté par  . Évalué à 5.

      En principe, un outil d'analyse statique doit être prouvé formellement. En effet, il est inutile de vérifier un programme par un autre programme si les deux sont potentiellement aussi faux l'un que l'autre. Autant passer du temps en relecture de code. On doit donc déterminer le type d'analyse qu'on doit effectuer et les propriétés qu'on veut étudier et démontrer formellement (mathématiquement) que cette analyse fonctionne.
      Le problème, c'est qu'il faut définir premièrement la sémantique du programme, c'est à dire du langage de programmation utilisé et deuxièmement, il faut se rendre compte que cette analyse est "moins précise" qu'une exécution exhaustive de tous les états possibles du programme, qui est infiniment précise mais aussi potentiellement infiniment longue. On doit donc s'assurer que notre représentation "moins précise" permet une analyse en temps fini et que les résultats ont encore un sens dans le programme réel : c'est un compromis pas toujours simple.
      Tout ça pour dire que la plupart des analyseurs statiques du marché ont un noyau correctement prouvé, mais qu'on fait aussi pas mal de compromis pour obtenir un résultat raisonnable.

      • [^] # Re: SWAT exempté?

        Posté par  . Évalué à 5.

        En effet, il est inutile de vérifier un programme par un autre programme si les deux sont potentiellement aussi faux l'un que l'autre.
        Du moment qu'il trouve des bugs que le développeur peut confirmer ensuite, ce n'est pas inutile.

        • [^] # Re: SWAT exempté?

          Posté par  (site web personnel) . Évalué à 0.

          Du moment qu'il trouve des bugs que le développeur peut confirmer ensuite, ce n'est pas inutile.

          En général oui, mais pas toujours : pour une commande de vol électrique d'avion de ligne, il faut prouver que le logiciel est complètement correct.
          Mais bon, comme passer d'un bon auxiliaire dans la chasse au bug à la preuve formelle du programme implique des changements considérables dans le processus et les outils de développement, ce n'est franchement pas applicable sur le kernel (et au logiciel libre en général, d'ailleurs).

  • # lien en français

    Posté par  (site web personnel) . Évalué à 1.

    http://fr.news.yahoo.com/041214/7/46ksx.html(...)

    • [^] # publiés?

      Posté par  . Évalué à 1.

      Ces bugs ont ils été publiés? Si oui, où peut on trouver la liste des lignes de codes qui posent problème? C'est facile de dire "il y a N bugs" sans en donner la liste...

Suivre le flux des commentaires

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