IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

La manie du test mémoire


Sujet :

C

  1. #1
    Inactif  

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    534
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 534
    Points : 403
    Points
    403
    Par défaut La manie du test mémoire
    Salut,

    Quand je regarde tous ces petits morceaux de programmes je me pose des questions :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
     
     
    typedef struct toto
    { int a ;
      int b ; 
    } toto ;
     
    toto * alloctoto()
    { toto * t = (toto*) malloc( sizeof(toto)) ; 
      if( t == NULL ) 
      exit(1) ; else 
      return t ; 
    }
    La question c'est que dans dans "alloctoto()" la condition nulle ne sera jamais réalisée, sauf à être vraiment impromptue.

    Un système d'exploitation à 32 bits et plus, permet une gestion de la mémoire ( virtuelle ou linéaire ) qui semble pouvoir se passer des habitudes mémoires de la programmation en 16 bits.

    Java et .Net se moquent des retours d'allocation mémoire. Le "garbage collector" gère la mémoire du système dans ses limites .

  2. #2
    Membre Expert

    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2003
    Messages : 4 506
    Points : 5 724
    Points
    5 724
    Par défaut
    En même temps ca permet de décrire un comportement dans ton exemple c'est l'application qui se termine. En Java il y a une machine virtuelle derrière donc tu alloues ce que tu veux quand tu veux (trés optimiste chez sun) et si la jvm ne trouve plus de place alors elle va générer une exception dans ton programme et cela tu es obligé de le traiter donc...
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  3. #3
    Inactif  

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    534
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 534
    Points : 403
    Points
    403
    Par défaut
    Salut,

    Citation Envoyé par hegros
    En même temps ca permet de décrire un comportement dans ton exemple c'est l'application qui se termine. En Java il y a une machine virtuelle derrière donc tu alloues ce que tu veux quand tu veux (trés optimiste chez sun) et si la jvm ne trouve plus de place alors elle va générer une exception dans ton programme et cela tu es obligé de le traiter donc...
    Effectivement java propose des exceptions en cas de défaillances mémoires à condition les traiter.

    En fait les défaillances mémoires ne sont que rarement observées, selon la jvm de java, ou le petit programmeur en C, avec un système d'exploitation 32 bits.

    Il est délégué au système d'exploitation des tâches qui paraissaient relever du développeur ( la mémoire ? ).

    .Net et java entre autres, semblent relever de cette approche.

  4. #4
    Membre Expert

    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2003
    Messages : 4 506
    Points : 5 724
    Points
    5 724
    Par défaut
    Citation Envoyé par dj.motte

    En fait les défaillances mémoires ne sont que rarement observées, selon la jvm de java, ou le petit programmeur en C, avec un système d'exploitation 32 bits.
    Tu en as déja observé ? Certains comportements ou instabilité d'un programme peut être dûs à une mauvaise utilisation de la mémoire.
    En C ce qui peut revenir c'est un pointeur NULL ou non initialisé par lequel on tente d'accèder à une donnée. Il est difficile d'observer ce genre de défaillance car parfois même avec un pointeur dans les choux le programme tourne.
    Encore un autre exemple l'allocation massive de data sans libération. Essaie de faire communiquer 2 programmes par une file de message et oublie d'effacer les messages à traiter et tu te retrouves avec une file pleine au bout x temps et un système qui ne communique plus...
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  5. #5
    Expert confirmé

    Inscrit en
    Août 2006
    Messages
    3 941
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 3 941
    Points : 5 652
    Points
    5 652
    Par défaut
    Fao,
    Citation Envoyé par dj.motte
    La question c'est que dans dans "alloctoto()" la condition nulle ne sera jamais réalisée, sauf à être vraiment impromptue.
    Rien ne t'empêche de ne jamais vérifier le résultat d'une allocation mémoire, mais le jour où un de tes programmes "qui marchait très bien" se met à partir dans les choux, il ne faudra pas venir te plaindre.

    Que préfères-tu : vérifier systématiquement, ou être plus tard obligé d'éplucher ton code, en y ajoutant cette vérification, entre autres, ce qui risque de te prendre pas mal de temps, et de t'énerver quelque peu, de surcroît.

    Une bonne habitude en programmation est de toujours vérifier le retour des fonctions d'appel au système, et de faire que le programme réagisse correctement en cas d'échec.
    Si les cons volaient, il ferait nuit à midi.

  6. #6
    Rédacteur
    Avatar de Franck.H
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2004
    Messages
    6 951
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Service public

    Informations forums :
    Inscription : Janvier 2004
    Messages : 6 951
    Points : 12 462
    Points
    12 462
    Par défaut
    Je serais plus court que les autres.... Cette vérification relève de la bonne programmation et donc de bonnes habitudes tout simplement !
    Mon Site
    Ma bibliothèque de gestion des chaînes de caractères en C

    L'imagination est plus importante que le savoir. A. Einstein

    Je ne répond à aucune question technique par MP, merci d'avance !

  7. #7
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Salut,

    L'un des principes "de bonne programmation" demande à ne laisser aucun cas non géré... aussi improbable que puisse etre ce cas.

    Or, quelle que soit la quantité de mémoire dont tu *crois* pouvoir disposer (ce n'est pas forcément parce que tu as 16Gb de mémoire que tu peux disposer d'autant pour ton application ) l'un des cas qui peut apparaitre lors de la (tentative d') allocation dynamique est... qu'elle échoue.

    Simplement parce qu'il ne faut jamais oublier que ton application n'est peut etre pas la seule à tourner, que certains systèmes d'exploitation mettent une limite sur la quantité de mémoire utilisable par processus, parce que certains besoins sont, réellement, tres gourmands en mémoire, j'en passe et de meilleures...

    Il se fait que, si elle échoue, ton programme peut tres bien continuer à fonctionner un certain temps avant que les effets ne s'en fassent ressentir, avec des résultats catastrophiques pour le système lui-meme.

    Le cas se trouve d'ailleurs dans tout ce qu'on peut nommer "appels système": il n'y a à priori aucune raison que l'ouverture en écriture (ou en "append") d'un fichier n'échoue... Sauf qu'un utilisateur distrait peut aussi avoir lancé une action "bloquante" sur ce fichier...

    Le fait de ne pas tester le retour de ces "appels système" revient le plus souvent, meme si cela fait gagner (au mieux) quelques fréquences d'horloge, à jouer à la roulette russe, tant pour l'application elle-meme que pour le système complet.

    Je ne suis personne pour t'obliger à vérifier systématiquement le retour d'une allocation dynamique ou l'ouverture d'un fichier...

    Mais, si tu décides de ne pas le faire, il ne faudra pas venir pleurer chez moi à cause une erreur de segmentation, ou parce que ca aura provoquer le crash définitif de ton OS

    Quelques détails concernant les fonctions *alloc encore...

    Le cast du malloc n'est plus nécessaire en C: les codes suivants fonctionnent tres bien
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    toto * t =  malloc( sizeof(toto)) ;
    /* voire */
    toto * t = malloc( sizeof(*t)) ;
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  8. #8
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    Juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Points : 4 637
    Points
    4 637
    Par défaut
    Citation Envoyé par dj.motte
    Un système d'exploitation à 32 bits et plus, permet une gestion de la mémoire ( virtuelle ou linéaire ) qui semble pouvoir se passer des habitudes mémoires de la programmation en 16 bits.
    Si ce n'est que le C n'est pas limite a des plateformes 32bits avec 4Go de RAM, etc. avec un programme one shot tres bref. Mais tourne aussi sur des architectures tres contraintes en memoire et/ou la demandant une disponibilite permanente et là ce test est indispensable .
    En outre meme si ce test n'est pas forcement indispensable (quoique ?) dans certains cas bien precis, il n'est pas non plus nuisible dans ces cas et devient vite indispensable dans d'autres cas. Donc plutot que faire des suppositions hasardeuses du style "Ai-je vraiment besoin de tester le retour de l'allocation ici ?" qui se reveleront probablement fausse a un moment donnee ou a un autre autant travailler proprement et tester les retours de fonction.

    Citation Envoyé par dj.motte
    Java et .Net se moquent des retours d'allocation mémoire. Le "garbage collector" gère la mémoire du système dans ses limites .
    Et leve une exception qu'il faut traiter en cas d'erreur. La problematique est la meme, les controles doivent la encore etre fait. LA seule difference se situe dans la facon dont est remonte l'information.


    Maintenant si tu preferes travailler salement et ne pas verifier les retours d'allocation, c'est ton choix mais il ne faudra pas etre etonne le jour ou ca ne fonctionnera plus.

  9. #9
    Expert éminent sénior
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Points : 20 985
    Points
    20 985
    Par défaut
    Citation Envoyé par dj.motte
    Quand je regarde tous ces petits morceaux de programmes je me pose des questions :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    typedef struct toto
    { int a ;
      int b ; 
    } toto ;
     
    toto * alloctoto()
    { toto * t = (toto*) malloc( sizeof(toto)) ; 
      if( t == NULL ) 
      exit(1) ; else 
      return t ; 
    }
    La question c'est que dans dans "alloctoto()" la condition nulle ne sera jamais réalisée, sauf à être vraiment impromptue.
    Je ne sais pas ce que tu entends par 'impromptue', mais le langage C dit que malloc() retourne une adresse valide ou NULL en cas d'echec.

    L'échec doit donc être envisagé. Le choix du exit(1) est discutable (je préfère laisser l'application décider de la suite à donner, une erreur d'allocation n'est pas forcément fatale), mais l'erreur d'allocation est toujours possible. Sa probabilité dépend de facteurs indépendants du langage C, et on ne programme pas sérieusement en se basant sur les probablilités.

    Donc le test doit être fait. Toujours.
    Pas de Wi-Fi à la maison : CPL

  10. #10
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Entièrement d'accord avec mes prédecesseurs

    Et je rajouterais même :

    Citation Envoyé par dj.motte
    ..
    La question c'est que dans dans "alloctoto()" la condition nulle ne sera jamais réalisée, sauf à être vraiment impromptue.
    ..
    Oui ça arrive. ça m'est arrivé avec une grosse appli tournant 24/24 7/7 (et pourtant avec 1GO de RAM) au bout de 5 jours de runtime...

    Et là, ben t'es bien mal (et ton assurance a intérêt à être costaud) si tu n'as pas prévu de gérer ça.....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [RAM] Test mémoire "avec Live CD Ubuntu" -> 104 erreurs
    Par damien7307 dans le forum Composants
    Réponses: 2
    Dernier message: 26/03/2010, 20h38
  2. allocation mémoire puis test générique
    Par contremaitre dans le forum C
    Réponses: 15
    Dernier message: 04/02/2008, 20h18
  3. test d'une allocation dynamique de mémoire
    Par gotrunkssj dans le forum C
    Réponses: 7
    Dernier message: 27/01/2008, 22h41
  4. [Outils de test] Profiling et test de fuites mémoire
    Par Playmo dans le forum EDI/Outils
    Réponses: 7
    Dernier message: 23/06/2006, 15h31
  5. [System]Test si programme déjà chargé en mémoire
    Par Eric SAULNIER dans le forum C++Builder
    Réponses: 2
    Dernier message: 14/10/2005, 13h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo