Bonjour,
voilà je programme en C et je voudrais savoir si dans un programme C
on utilise malloc mais sans faire de free dans le même programme (je veux dire sans liberer de la mémoire) est-ce que celà a des conséquence ?
les quelles ?
merci.
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
les conséquences de malloc
Bonjour,
voilà je programme en C et je voudrais savoir si dans un programme C
on utilise malloc mais sans faire de free dans le même programme (je veux dire sans liberer de la mémoire) est-ce que celà a des conséquence ?
les quelles ?
merci.
Si tu utilises malloc sans faire de free alors tu peux te retrouver saturé à un instant. Remarque un vrai programmeur ne fait jamais de malloc sans faire de free derrière.
Une bonne pratique est que dés que tu poses le mot malloc tu mets tout de suite derrière le free pour ne pas oublier.
C'est donc une erreur de programmation que de ne pas libérer la mémoire soit -2 pour chaque free n'ont réalisé
Normalement et je dit bien normalement, le système sous-jacent de ton OS devrais s'occuper de la libération des ressources mais j'en suis pas sûr qu'ils le font tous
Vu que je ne fait confiance qu'à moi même, la règle d'or est donc:
1 *alloc = 1 free
Mon Site
L'imagination est plus importante que le savoir. A. Einstein
Je ne répond à aucune question technique par MP, merci d'avance !
La mémoire utilisée par malloc est la mémoire vive ou mémoire du disque dur ?
En mémoire vive tu t'imagines le temps d'accès aux disquesEnvoyé par momeftah
Mais une allocation de mémoire avec les fonctions *alloc ca se fait dans le tas donc dans la RAM et jamais sur disque
L'imagination est plus importante que le savoir. A. Einstein
En fait non, tu demandes au système à ce qu'il t'alloue de la mémoire, tu ne sais pas d'où elle provient, de plus, si tu n'as pas assez de RAM, le système va chercher la mémoire sur le disque.En mémoire vive tu t'imagines le temps d'accès aux disques
Pour moi elle provient forcément de la RAM pour la mémoire du disque tu fais peut etre référence au swapping ?
En fait tu demandes l'allocation d'un bloc de mémoire, celui ci peut être en RAM ou sur le disque. Si tu demande l'allocation d'un giga et que ta machine ne dispose pas de cette quantité en RAM, le système utilise le disque (le SWAP si tu veux).Pour moi elle provient forcément de la RAM
Je ne suis pas totalement d'accord avec ta remarque. Si tu demandes 1 GIGA le système te donnera 1GIGA virtuel mais cela n'est ni en RAM ni sur disque
Lorsqu'un programme accéde à une variable d'un programme cette dernière est forcément remontée en RAM et n'est normalement plus sur disque même si à un instant elle pouvait y être.
Si je veux faire une incrémentation sur une variable i et que j'alloue cette dernière avec malloc alors qu'il n'y a plus de RAM disponible alors le système fera de la place et fera un swapping de ce qu'il lui semble correct pour réaliser l'opération ensuite on a le schéma : ram->registre processeur(incrémentation)->ram
si par exemple j'utilise la mémoire SWAP pour manque de mémoire vive alors cette mémoire SWAP ne va pas être liberée si je n'utilise pas de free dans mon programme ?
Et donc ça va bouffer de la mémoire du disque?
De toute manière le swap sur les système est soit un fichier soit une partition. De manière parfaite, si le système est bien conçu, le swap sur fichier devrait se faire sur un fichier de taille fixe et là tu ne verrai rien. Il se trouve que ça n'est pas toujours le cas, le fichier d'échange a quelques fois une taille dynamique. Si le système en plus ne s'occupe pas de libérer la mémoire à la fin de l'exécution de ton programme tu vas donc avoir un espace disque inutilisable pour rien (jusqu'au prochain redémarrage).si par exemple j'utilise la mémoire SWAP pour manque de mémoire vive alors cette mémoire SWAP ne va pas être liberée si je n'utilise pas de free dans mon programme ?
Et donc ça va bouffer de la mémoire du disque?
De toute façon, en programmation il faut être rigoureux et ne pas se reposer sur des supputations hazardeuses : comme Franck.H l'a dit : 1 alloc = 1 free. Toute autre chose est (de mon point de vue) une erreur de programmation. De plus, il se peut qu'au court de ton programme une partie de la mémoire que tu as alloué ne te soie plus nécéssaire, si cette zone est relativement grande, il vaut mieux la libérer pour éviter de swapper (et tout le mécanisme qu'a cité hegros).
C'est pas ce que j'ai dis ?Si tu demandes 1 GIGA le système te donnera 1GIGA virtuel mais cela n'est ni en RAM ni sur disque
En fait je me rend compte que nous ne parlons pas de la même chose, je répondait plus à cette question :
La mémoire utilisée par malloc est la mémoire vive ou mémoire du disque dur ?
Sous unix (je parle d'unix car je ne sais pas vraiment comment fonctionne windows là dessus). Lorsque tu crées un processus, le système va faire une demande pour le mettre sur le disque, mais se retrouve normalement en mémoire vive grace au buffer cache. Et c'est toute la partie Buffer Cache qui s'occupe de ça, c'est transparent pour tout le monde (il y a en gros des primitives getBlock et releaseBlock qui permet de récuperer de l'espace, qui se trouvera soit en RAM, soit sur le disque, le buffer cache aura tendance à garder en mémoire les blocs les plus utilisées (comme les processus...) et les derniers utilisés (suivant la loi de proximité spatiale et temporelle, et il y a d'autres techniques plus fines)
Il faut libérer la mémoire que tu alloues qu'elle soit physique ou virtuelle car la "purge" ou "ramasse miette" après ca dépend des systèmes.
maintenant je comprends pour quoi mon pc plante au démarrage en mode console au lieu du mode graphique; je crois que c'est du à ça !!
mon système ne s'occupe pas de liberer de la mémoire après éxecution d'un porgramme.
Que-ce que vous pensez ?
C'est quoi ton système ? Et ne me dis pas MS...qui se trouve ici
Une fois le processus terminé, le système détruit complétement le processus, donc tu recupères toute la mémoire qu'il a pu demandé (encore heureux d'ailleurs)
mmmm je sais pas trop... Mes constatations sous W**** ne vont pas trop dans ce sens-là.. Mais je n'y connais rien, juste un utilisateur.. Sous unixoide oui c'est vrai....
Mais tu peux arriver à faire planter un système unixoide quand même
Mas bon, vu les tailles en général, ça pose pas de problème. Par contre, historiquement, il me semble que au moins jusqu'à Win98, M$ ne gérait pas de swap et tout se passait en RAM (d'où les innombrables (et parfaitement clairs pour l'utilisateur lambda) "Fatal Error %x007FFF" où il n'y avait pkus qu'à éteindre et rebooter)..
C'est pour ça que j'ai dit : Une fois le processus terminé. Si il termine pas, alors c'est sûr, ça peut tellement ramer que tu peux ne pas réussir à l'arrêterMais tu peux arriver à faire planter un système unixoide quand mêmeSinon, je connais mieux les systèmes Unix que windows, ce que j'avais aussi dit précédemment avec les buffer caches, je ne sais pas du tout comment c'est géré sous windows.
je suis sous linux avec mandrake 10.1 je sais c'est un peu démodé
Répondre avec citation
Partager