La manie du test mémoire

Version imprimable

10/06/2007, 01h29
dj.motte

La manie du test mémoire
Salut,

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

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 .
10/06/2007, 01h41
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...
10/06/2007, 02h35
dj.motte

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.
10/06/2007, 03h04
hegros

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...:yaisse2:
10/06/2007, 09h26
droggo

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. :D

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.
10/06/2007, 10h05
Franck.H

Je serais plus court que les autres.... Cette vérification relève de la bonne programmation et donc de bonnes habitudes tout simplement !
10/06/2007, 10h37
koala01
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:

1 2 3 toto * t = malloc( sizeof(toto)) ; /* voire */ toto * t = malloc( sizeof(*t)) ;
10/06/2007, 10h38
gl

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.
10/06/2007, 12h47
Emmanuel Delahaye
Citation:
Envoyé par dj.motte

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

Code:

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.
10/06/2007, 17h59
souviron34

Entièrement d'accord avec mes prédecesseurs :mrgreen:

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.....