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
Allocation mémoire et interruption de programme
Hello,
Supposons que j'ai un programme qui, dés qu'un malloc a échoué, quitte avec exit(1). Je me demandais simplement de ce que devenait la mémoire qui avait été alouée précédement?
Faut-il libérer cette mémoire ou bien ca se fait automatiquement?
Merci d'avance
Sur un système évolué, la mémoire appartient au processus, et est libéré quand le processus se termine.
Sur des systèmes embarqués, ce n'est pas dit...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Ok donc sur un système non embarqué (type ordinateur linux/windows quelconque), la mémoire est bien libérée automatiquement ? Car si ce n'est pas le cas, il faudrait en quelque sorte stocker tous les pointeurs qui ont été alloué dans une sorte de variable globale (tableau) et les libérer lorsqu'on souhaite quitter le programme prématurément...
J'ai du mal a comprendre, lorsqu'on fait un malloc, on a toujours insisté sur la necessité de faire un free sous peine de garder une portion de mémoire réservée pour rien une fois le programme terminé... Or, que l'on quitte un programe prématurément ou qu'il se termine normalement, il me semble que ces deux situations sont équivalentes, et que donc si on doit absolument libérer la mémoire lorsque le programme se termine normalement, il semble logique qu'il faille aussi la libérer lorsqu'on le quitte prématurément...
Y aurait-il quelque chose qui m'échappe?
Cela fait partie d'une bonne habitude de programmation à savoir, libérer ce qu'on a alloué !Envoyé par vinzzzz
Mon Site
L'imagination est plus importante que le savoir. A. Einstein
Je ne répond à aucune question technique par MP, merci d'avance !
Oui bien sur... Mais si je dois libérer ma mémoire lorsque je quitte un programme brutalement, ca nécéssite tout de même de mettre en place une structure adaptée pour faire ca... Tandis que si elle est automatiquement libérée, on peut s'en passer.
Ce n'est peut-être pas le cas pour tous les systèmes, surtout si tu donnes dans la portabilité, je pense que c'est un point à prendre en considération !
L'imagination est plus importante que le savoir. A. Einstein
et de plus suivant le système de gestion de l'OS, la mémoire libérée lorsqu'un processus meure n'est pas forcément non plus réellement libérée de suite...
En fait, le fond du problème, est pourquoi compter sur quelqu'un d'autre quand on peut le faire soi-même ?
De plus, c'est une bonne habitude à prendre, car, (et il suffit pour s'en rendre compte d'avoir assez longtemps utilisé des softs sous Windows, qui pour beaucoup ne sont pas "safe" de ce côté-là), au départ, c'est juste la mémoire qu'on voudrait libérer, mais il peut y avoir des sockets, des liaisons avec des BD, etc etc...
Comme disait Franck.H c'est de la bonne pratique, c'est comme fermer une parenthèse ouverte.. Symétrique et logique...
En théorie, et pour du code 'jetable', oui.
Mais dans l'industrie, le code validé, ça coûte cher. Quand on écrit un nouveau programme, on cherche à réutiliser ce qui a été fait précédemment, et si on écrit du code nouveau, on cherche à ce qu'il soit réutilisable. Donc on travaille avec des 'briques' logicielles autonomes qui ont leur propres 'constructeurs'/'destructeurs' gérant proprement et efficacement la mémoire. Les détails ne sont pas visibles de l'utilisateur, mais ils doivent être conçus et codés correctement, car on ne sait pas d'avance quelles seront les conditions d'utilisation.
Théorie : http://emmanuel-delahaye.developpez.com/tad.htm
Réalité : http://emmanuel-delahaye.developpez.com/clib.htm
Oui tout ce que vous dites semble bien logique... C'est clair que quitter un programme en laissant des variables alouées, même si ca passe parfois, c'est pas super propre...
Ca complique pas mal le code: je quitte mon programme, il faut donc retrouver tous les pointeurs qui ont été alloués et qui doivent donc être libérés. Pour faire ca, je vois pas d'autre solution que de faire une variable globale (ou statique même), type liste de void*, qui va stocker tous les pointeurs de base ayant été aloués, et sur laquelle on bouclera une fois que le programme va se terminer brusquement.
Ce type de solution vous parait-elle honorable? Ca me semble assez chiant et lourd a gérer (il faudrait alors retirer les pointeurs désaloués au cours du programme), mais l'autre solution que je vois, ie. retourner pour chacune de mes fonctions un flag et les tester a chaques fois, me semble également assez compliquée et nécessitant pas mal de changements (mes fonctions renvoient parfois des résultats etc..)..
Bref si vous avez une solution miracle n'hésitez pas
Déjà répondu. C'est une question d'organisation structurée du code. Tu as lu les liens ? Il y a un moment où il faut arrêter de bricoler et se mettre coder sérieusement et avec méthode...
C'est bien ce que j'essaye de faire.
Dans ma pratique, si une fonction ne parvient pas à faire une allocation dynamique, je libère la mémoire précédamment allouée dans le corps de la fonction en cours et renvoie un code d'erreur explicite à la fonction appelante qui aura la responsabilité de réagir comme elle l'entend à cet échec (éventuellement réallouer plus tard, réallouer plus petit, utiliser un pool de mémoire pré-alloué pour les cas d'urgences, etc.).
Si la fonction appelante ne sait elle-même pas comment réagir à cet échec, elle renvoie un code d'erreur à la fonction qui l'as appelée, et ainsi de suite jusqu'à main() qui décidera si il est nécessaire de quitter le programme. C'est très schématique et je n'ai pas l'expérience des très gros projets où j'imagine que cela n'est pas toujours aussi simple. Chez moi en tout cas, seul main() est autorisé à quitter le programme. Cette stratégie me permet d'assurer que toute les resources ont été libérées au moment où le programme quitte.
Thierry
"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
+
Oui ca me semble être la méthode la plus propre...
En revanche, devoir tester à chaque fois dans chaque fonction appelante un code d'erreur (sachant que l'erreur à déja été repérée dans le code, là ou l'allocation a échouée) peut grandement ralentir le programme... En tout cas dans les aplications que je développe (type numériques) qui réalisent des millions de fois certains enchainements d'appels de fonctions.
Mais bon si on veux un code fiable, robuste et portable, on a pas le choix je suppose.
La question ne se pose que dans les phases d'initialisation. Une fois que l'objet est créé, on a plus besoin de tester grand chose...
La stratégie habituelle dans les algorithmes temps réel est de limiter le nombre de créations en anticipant au maximum ... Rien que du bon sens ordinaire...
non, on n'a pas le choix..
Quant a la vitesse, aucun ralentissement si le code est bien fait...
ne prend pas franchement du temps...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Il faut éviter autant que possible les globales. Ma solution et celle que j'utilise quand je fait beaucoup d'allocations lors de la vie du programme, c'est d'utiliser un gestionnaire d'allocations ! On peut s'en faire un soi-même, si c'est fait correctement, le programme libère alors automatiquement la mémoire lors de sa sortie (par return ou un exit). Dans mon cas cela ajoute un peu d'allocation supplémentaire pour la gestion de la liste des adresses allouées mais au prix rentable d'une application propre.
L'imagination est plus importante que le savoir. A. Einstein
Il faut bien tester si la création de l'objet s'est bien déroulée, et renvoyer un flag si ce n'est pas le cas, flag qui devra être testé par toutes les fonctions appelantes.
Anticiper, bien entendu, mais on a pas toujours le choix.
Oui je sais pas, si F1 appele F2 qui appele F3 puis F4 ... puis FN, et que dans chacune d'entre elles on vérifie la sortie, ca nous donne N tests a répéter des millions de fois... C'est peut être négligeable par ailleurs, je ne sais pas.
Quant aux gestionnaires d'allocations, je connais pas (encore
Ca n'existe pas, il faut le faire soi même ou bien en télécharger un comme par exemple sur mon site mais un exercice est bien de s'y mettre et le créer de toutes pièces.Quant aux gestionnaires d'allocations, je connais pas (encore
Cela peut se faire de différentes façons je suppose, le miens repose sur une liste chaînée qui contient toutes les adresses allouées par le biais des fonctions enveloppes de malloc/calloc/realloc/free qui font parties de la bibliothèque.
L'imagination est plus importante que le savoir. A. Einstein
C'est la même idée que ce que j'ai décrit plus haut? En quelque sorte, un fichier gestionnaire.c dans lequel il y aura une variable statique contenant les pointeurs aloués.
Ensuite des fonctions qui gèrent cette liste: supression des pointeurs désaloués au cours du programme (ca implique donc de l'appeler avant tout free(p)), ajout des nouveaux pointeurs, et une foncton qui libère le tout?
Je suppose que c'est un peu plus complexe que ca mais est-ce qu'au moins je ne suis pas totalement à coté de la plaque?
Ok ca semble être à peu prés ca donc.
Répondre avec citation
Partager