gestion d'allocation (similaire au garbage collector).

Bonjour,

Je voudrais faire une gestion d'allocation/désallocation dans mon programme.
J'ai donc suivi ce tuto

http://haypo.developpez.com/article/halloc/

Quelque point sont encore obscure, mais je m'en dépatouille.
Bref, ce que je voudrais, c'est étendre ceci aux librairie externe.

J'ai bien compris que malloc/free & Cie etait "rediriger" vers une autre fonction grace aux define, mais cette redirection ne marche que si on a inclue GestionMemoire.h (c'est comme ca que je l'appele).
Par contre, les malloc/free & Cie d'une librairie tel que la SDL ne seront pas rediriger car il n'y a pas le include.

D'ou mes question :

* Peut-on demander que les malloc/free d'une lib externe soit rediriger grace aux define de GestionMemoire.h ?
* Peut-on mettre une option dans le makefile qui nous permettrait d'inclure GestionMemoire.h partout sans qu'il y ait d'appel explicite dans le code ?
* Si oui, cela marcherai t'il pour la SDL ?

J'ai bien une idée de réponse (non), mais comme il se peut que je sois passé a coté de quelque chose, je demande.

Merci de votre lecture.

Le plus souvent, tu vas devoir considèrer que la lib que tu utilises est irréprochable.

ce qu'il faut surveiller ce sont tes allocs et désallocs...

Dans le cas de la SDL que tu cites, comment veux tu, avec le préprocesseur jouer sur une lib dèjà compilée? Oo...

Le trou s'il y a c'est toi qui le provoque, donc tu dois surveiller tes alloc...
Rien ne t'empèche de créer des (fonctions, macros...), pour chaque fonction de la lib que tu utilise qui crèe ou libère des ressources.

C'est donc bien ce que je pensait.

En fait, j'aurais préférer "détecter" tout les malloc, car ca m'aurait amplement simplifier la vie.

J'explique.
Dans le cas de simple malloc dans mon programme sans aucune lib externe (mis a part stdlib.h), aucun soucis.
Mon questionnement provient du fait que souvent, en cas d'erreur, je fait un bel
exit (EXIT_FAILURE) en laissant a charge de l'OS de tout desalloué.
Or, ce n'est pas propre et surtout, tout les OS ne font pas des desallocation en fin de vie de programme.
Donc, ce que j'aurai voulu, c'est savoir quand la fonction malloc est appelé et sur combien de mémoire pour que je puisse lister et donc vider ces allocations.
Le probleme survient avec les malloc par fonction interposé, comme fopen pour FILE*, SDL_LoadBMP pour SDL_Surface* et ca continue.

Si je ne peux pas detecter les malloc, alors je dois detecter les appel a fonction (fopen, SDL_LoadBMP ...) et surtout, je dois retenir quelle fonction je devrais appelé en cas de probleme.

Ca engendre donc une surcharge de fonction alors que si on avait accées au appel malloc, ca serait plus simple.

D'ou mes question qui peuvent te paraitre idiote, mais voila, je sais pas tout et j'esperai une petite astuce.


Je devrais donc refaire toute les fonction d'appel ...

Citation:

---

Envoyé par SofEvans

Or, ce n'est pas propre et surtout, tout les OS ne font pas des desallocation en fin de vie de programme.

---

Ce n'est pas "propre", c'est optimisé.
La mémoire virtuelle est fonction d'un processus, si on kill l'application, cette mémoire qui comme son nom l'indique est virtuelle, n'existe plus.
Certes ont pourrais en trouver trace dans la ram et alors?
Il ne faut pas vider la mémoire après avoir fini de l'utiliser mais l'initialiser avant de l'utiliser, c'est tout :)
C'est a l'OS de gerer la ram pas a ton application.

Citation:

---

Envoyé par SofEvans

Donc, ce que j'aurai voulu, c'est savoir quand la fonction malloc est appelé et sur combien de mémoire pour que je puisse lister et donc vider ces allocations.

---

Tu entends quoi par vider? mettre 0 partout?
Si tu y tiens vraiment, tu appeles atexit avec ta fonction my_free qui fait memset sur tout le heap mais l'interet est absolument nul.

Citation:

---

Envoyé par SofEvans

Ca engendre donc une surcharge de fonction alors que si on avait accées au appel malloc, ca serait plus simple.

---

Tu peux utiliser ton malloc partout, sous les systemes unix il te suffis de renseigner la variable LD_PRELOAD dans un shell.
Il est d'ailleurs révélateur d'ajouter un compteur (en variable statique) au fonction malloc et free et de faire une simple soustraction sur des applications comme firefox ou the gimp :mouarf:

Citation:

---

Envoyé par sloshy

Ce n'est pas "propre", c'est optimisé.
La mémoire virtuelle est fonction d'un processus, si on kill l'application, cette mémoire qui comme son nom l'indique est virtuelle, n'existe plus.
Certes ont pourrais en trouver trace dans la ram et alors?
Il ne faut pas vider la mémoire après avoir fini de l'utiliser mais l'initialiser avant de l'utiliser, c'est tout :)
C'est a l'OS de gerer la ram pas a ton application.

---

Tu comptes ici sur le fait que l'OS libère automatiquement toute la mémoire allouée par programme lors de la fin de l'exécution. Ce comportement est effectivement celui présent sur de nombreux systèmes (dont Linux et Windows) mais n'est pas, à ma connaissance, garantie partout.

Si le but est de faire un programme portable sur des systèmes n'ayant pas ce comportement sans provoquer de fuite mémoire, il faut bel et bien libérer toute la mémoire allouée dynamiquement soi-même et ne pas compter sur l'OS pour le faire.

Citation:

---

Envoyé par sloshy

Tu entends quoi par vider? mettre 0 partout?

---

Dans le cadre de la question, je comprends plutôt "libérer" (donc appel à malloc).
C'est vrai que le terme "vider" n'est pas le plus clair qu'il soit.

La seul chose libérable sur un systeme (disposant d'un OS s'entend) est le heap. un simple brk(0); sur une fonction pointee par atexit() et on en parle plus.
Hors c'est le role d'un OS de gerer la memoire globale, pas d'une application utilisateur.

Il faut faire confiance a l'OS pour ca.

Citation:

---

Envoyé par sloshy

La seul chose libérable sur un systeme (disposant d'un OS s'entend) est le heap. un simple brk(0); sur une fonction pointee par atexit() et on en parle plus.
Hors c'est le role d'un OS de gerer la memoire globale, pas d'une application utilisateur.

Il faut faire confiance a l'OS pour ca.

---

Mais ce comportement est dépendant de l'OS justement.

Juste deux remarques :

• La mémoire n'est pas la seule ressource utilisée par une application. Et toutes les ressources ne sont pas libérées par l'OS en fin d'exécution (et heureusement pour certaines).
• Non ce n'est pas le rôle de l'OS seul de gérer la mémoire. Après tout c'est bien l'application qui demande de la mémoire. Et en soi, il n'est pas totalement aberrant de penser que l'entité qui acquiert une ressource en gère la libération.

J'ai l'impression qu'à partir de ta connaissance d'un système particulier (visiblement Linux), tu généralises ce comportement à tous les systèmes. Or ce n'est pas le cas, il existe de nombreuses différences d'un système à l'autre.

d'ailleurs Windows ne libère la mémoire allouée par une application automatiquement en fin de processus, que dans des cas bien précis...

n'oublie pas que tous les OS ne fonctionnent pas de la même façon.
il n'y a encore pas si longtemps, Windows ne libérait pas du tout la mémoire allouée sur le tas par une application quand elle quittait si elle ne le faisait pas elle même, et comme déjà dit il ne le fait que dans des cas précis.

sous Windows tu peux allouer de la mémoire avec malloc/realloc/free et bien entendu en C++... new/delete... ces fonctions utilisent les fonctions de la libc... quand tu alloue de la mémoire avec ces méthodes, elle est nettoyée en fin de process. (si aucune règle spécifique de compilation de ton application n'a pas perturbé ce fonctionnement)
mais tu peux appeler l'api Windows et allouer de la mémoire via les méthodes api, et là ce n'est plus la même histoire... dans ce cas la mémoire n'est libérée que si et seulement si tu fait de l'allocation temporaire en utilisant l'api pour la mémoire temporaire, ce que personne ne fait et utilise toujours l'api d'allocation globale.
la libc utilise l'allocation temporaire depuis les systèmes récents, mais utilisait l'allocation globale, il n'y a pas si longtemps que ca. (d'ailleurs si tu règle mal ton compilateur, tu peux perturber ce fonctionnement et faire en sorte que ce soit la méthode globale plutôt que "temporaire" qui soit utilisée.)

se baser uniquement sur le système pour nettoyer derrière toi prouve une seule et unique chose... que tu es un mauvais développeur et d'une fainéantise coupable. tu as probablement acquis cette mauvaise habitude auprès de langages sur plateforme managé comme Java ou C#, mais toute ressource réclamée doit être libérée par celui qui l'a appelé, et ce même sous linux... c'est un fondement de la programmation propre !
maintenant je reconnais qu'on peut en oublier parfois, même en faisant attention, et qu'effectivement c'est mieux qu'une sécurité de l'OS fasse le ménage, mais ce n'est pas une raison pour du coup ne pas le faire soit même ! en plus ce comportement ressemble à s'y méprendre à un développeur java, qui de toute façon ne permet pas une libération déterministe de la mémoire, malheureusement en temps que développeur tu devrais savoir qu'il est parfois indispensable de libérer la mémoire qu'on a allouée... certains algorithmes nécessites une libération déterministe sous peine de se faire killé par le système parce qu'on est trop gourmand.

d'ailleurs tu ne t'ai jamais demandé pourquoi certains fichiers n'étaient jamais refermés correctement ? pourquoi alors que plus rien ne les ouvre, le système t'envoie littéralement pêtre si tu veux les effacer, les déplacer ?
tout simplement parce que l'application qui à ouverte le fichier n'a pas libérée proprement la ressource, et là ouverte par des méthodes qui interdise au système de le fermer de lui même...
et oui Windows est plein de contrariétés et souvent parce que les développeurs ne savent pas développer, et non pas parce que l'OS est mal conçut ou mal pensé.

tu aimerais que des passants passent devant chez toi et foute toute leurs merdes dans ton jardin ? et quand tu va leur dire, oh vous pourriez ramasser... pfff on s'en fou, la mairie passe derrière nous, ou vous passerez bien derrière nous !
tu crois réellement que tu apprécierais ce genre de comportement ? et bien c'est exactement la même chose pour la mémoire que tu alloue sur un système, ou toute ressource, quelle qu'elle soit... la moindre des choses est de faire le ménage derrière soit, à moins qu'on ne soit un gros "porc" qui aime se vautrer dans la fange...
je trouve ce comportement de plus en plus répandu chez les développeurs (à cause de cette sécurité sur linux et de la libération non déterministe de java) particulièrement irritant, et vraiment insensé.

je comprend mieux pourquoi je peste après certaines appli qui bouffent des 100aine de méga en mémoire, alors qu'elles ne font rien d'exceptionnel...avec des développeurs aussi feignants que toi... ca ne peut pas aller en s'améliorant.

Citation:

---

Envoyé par cinemania

d'ailleurs Windows ne libère la mémoire allouée par une application automatiquement en fin de processus, que dans des cas bien précis...

n'oublie pas que tous les OS ne fonctionnent pas de la même façon.
il n'y a encore pas si longtemps, Windows ne libérait pas du tout la mémoire allouée sur le tas par une application quand elle quittait si elle ne le faisait pas elle même, et comme déjà dit il ne le fait que dans des cas précis.

sous Windows tu peux allouer de la mémoire avec malloc/realloc/free et bien entendu en C++... new/delete... ces fonctions utilisent les fonctions de la libc... quand tu alloue de la mémoire avec ces méthodes, elle est nettoyée en fin de process. (si aucune règle spécifique de compilation de ton application n'a pas perturbé ce fonctionnement)
mais tu peux appeler l'api Windows et allouer de la mémoire via les méthodes api, et là ce n'est plus la même histoire... dans ce cas la mémoire n'est libérée que si et seulement si tu fait de l'allocation temporaire en utilisant l'api pour la mémoire temporaire, ce que personne ne fait et utilise toujours l'api d'allocation globale.
la libc utilise l'allocation temporaire depuis les systèmes récents, mais utilisait l'allocation globale, il n'y a pas si longtemps que ca. (d'ailleurs si tu règle mal ton compilateur, tu peux perturber ce fonctionnement et faire en sorte que ce soit la méthode globale plutôt que "temporaire" qui soit utilisée.)

se baser uniquement sur le système pour nettoyer derrière toi prouve une seule et unique chose... que tu es un mauvais développeur et d'une fainéantise coupable. tu as probablement acquis cette mauvaise habitude auprès de langages sur plateforme managé comme Java ou C#, mais toute ressource réclamée doit être libérée par celui qui l'a appelé, et ce même sous linux... c'est un fondement de la programmation propre !
maintenant je reconnais qu'on peut en oublier parfois, même en faisant attention, et qu'effectivement c'est mieux qu'une sécurité de l'OS fasse le ménage, mais ce n'est pas une raison pour du coup ne pas le faire soit même ! en plus ce comportement ressemble à s'y méprendre à un développeur java, qui de toute façon ne permet pas une libération déterministe de la mémoire, malheureusement en temps que développeur tu devrais savoir qu'il est parfois indispensable de libérer la mémoire qu'on a allouée... certains algorithmes nécessites une libération déterministe sous peine de se faire killé par le système parce qu'on est trop gourmand.

d'ailleurs tu ne t'ai jamais demandé pourquoi certains fichiers n'étaient jamais refermés correctement ? pourquoi alors que plus rien ne les ouvre, le système t'envoie littéralement pêtre si tu veux les effacer, les déplacer ?
tout simplement parce que l'application qui à ouverte le fichier n'a pas libérée proprement la ressource, et là ouverte par des méthodes qui interdise au système de le fermer de lui même...
et oui Windows est plein de contrariétés et souvent parce que les développeurs ne savent pas développer, et non pas parce que l'OS est mal conçut ou mal pensé.

tu aimerais que des passants passent devant chez toi et foute toute leurs merdes dans ton jardin ? et quand tu va leur dire, oh vous pourriez ramasser... pfff on s'en fou, la mairie passe derrière nous, ou vous passerez bien derrière nous !
tu crois réellement que tu apprécierais ce genre de comportement ? et bien c'est exactement la même chose pour la mémoire que tu alloue sur un système, ou toute ressource, quelle qu'elle soit... la moindre des choses est de faire le ménage derrière soit, à moins qu'on ne soit un gros "porc" qui aime se vautrer dans la fange...
je trouve ce comportement de plus en plus répandu chez les développeurs (à cause de cette sécurité sur linux et de la libération non déterministe de java) particulièrement irritant, et vraiment insensé.

je comprend mieux pourquoi je peste après certaines appli qui bouffent des 100aine de méga en mémoire, alors qu'elles ne font rien d'exceptionnel...avec des développeurs aussi feignants que toi... ca ne peut pas aller en s'améliorant.

---

- Primo, je ne te permets pas de me juger :)

- Secondo, je n'ai jamais utiliser de .NET ou autre, juste du C, de l'asm et du python.

- Tierso, a chacun sa place, je free tout mes malloc, je close tout mes open. si je me rend compte que j'utilise une bibliothèque qui ne le fait pas, alors j'en change tout simplement.

Ensuite, je persiste et signe, certes l'application doit gerer sa propre memoire et ressource, mais l'OS n'a en aucun cas a lui faire confiance et DOIT repasser derrière, c'est bien connu, never trust the client, pour l'OS le client est le processus.

bref, retourne a ta salle de cine et evite d'attaquer les gens qui discute simplement

Citation:

---

Envoyé par sloshy

- Tierso, a chacun sa place, je free tout mes malloc, je close tout mes open. si je me rend compte que j'utilise une bibliothèque qui ne le fait pas, alors j'en change tout simplement.

---

J'ai probablement mal compris tes précédentes réponses car, en lisant ceci :

Citation:

---

Envoyé par sloshy

Ce n'est pas "propre", c'est optimisé.
La mémoire virtuelle est fonction d'un processus, si on kill l'application, cette mémoire qui comme son nom l'indique est virtuelle, n'existe plus.
Certes ont pourrais en trouver trace dans la ram et alors?
Il ne faut pas vider la mémoire après avoir fini de l'utiliser mais l'initialiser avant de l'utiliser, c'est tout
C'est a l'OS de gerer la ram pas a ton application.

---

Citation:

---

Envoyé par sloshy

Hors c'est le role d'un OS de gerer la memoire globale, pas d'une application utilisateur.

---

j'avais plutôt l'impression que tu préconisais de ne pas se soucier de libérer la mémoire en fin d'exécution.

Bref, cette incompréhension étant levée, il n'y a pas de souci.

Pour en revenir au fait que l'OS ne doit pas faire confiance à l'application et doit nettoyer derrière l'application :

• Quel que soit notre point de vue à ce sujet, il n'empêche que ce nettoyage n'est pas garanti et qu'il faut bien vivre avec.
• J'ai beaucoup de mal à être aussi affirmatif que toi sur ce que doit ou non faire un OS. Comme beaucoup d'autres sujets, c'est une histoire de compromis entre différents critères.

Que de reponse ^^

Merci de vous interresser a mon cas, meme si c'est un peu parti n'importe ou.
Bref, il apparaitrait que je ne puisse tout simplement pas savoir tout les malloc que le code ainsi que les librairie tierce font. Il faut donc que je "redirige" chaque methode soigneusement et que je retienne chaque fonction a appeler en cas de probleme.

Laborieux a mettre en place, mais ca pourrait être sympa.

Merci de vos reponse, et si vous avez une astuce ou une illumination, je suis preneur.

Bonjour, en quoi le LD_PRELOAD te pose problème? ca fait exactement ce que tu souhaites non? (il doit y avoir un équivalent en win32).

Si tu veux appliquer ton cas a l'ensemble du systeme un hook peut etre envisageable.

Bonjour,

Désolé, dans la masse d'info, c'est passé a la trappe, merci de me le rappeler.

Je vais voir ce que je trouve sur ce LD_PRELOAD et si ca me serai utile.

Par contre, un hook, j'ai du mal a voir. Pour moi, un hook, ca permet de recuperer les touche du clavier, a moins que hook soit une technique general et qu'une de ses applications soit ce que je viens d'évoquer.

Citation:

---

Envoyé par SofEvans

Par contre, un hook, j'ai du mal a voir. Pour moi, un hook, ca permet de recuperer les touche du clavier, a moins que hook soit une technique general et qu'une de ses applications soit ce que je viens d'évoquer.

---

C'est une technique générale. Ca consiste tout simplement à intercepter un message quelconque qui ne nous est pas destiné.

Citation:

---

Envoyé par SofEvans

Je vais voir ce que je trouve sur ce LD_PRELOAD et si ca me serai utile.

---

LD_PRELOAD permet de spécifier des .so qui seront traités avant tout autre. Ainsi les fonctions définies dans un de ces .so seront utilisées préférentiellement à toutes autres fonctions ayant la même signature.

Daccord, je comprend mieux.

Je vais donc creuser dans ce sens (les .so, LD_PRELOAD ne me sont pas familier) puis j'essayerai de faire un truc portable et pas dégueulasse.

Juste une question qui me taraude.

A supposer que j'arrive grace a LD_PRELOAD (ou a son equivalent windows) a intercepter TOUS les malloc qui se font, qu'en est-il pour la structure FILE* ?

Je veux dire, on sait que le type FILE* est une structure opaque qui change en fonction de l'environnement. Si mon programme plante sans qu'un FILE* qui a eu un fopen n'ai pu avoir de fclose, est ce que le fait de liberer les malloc aura la meme action que fclose, a votre avis ?

Citation:

---

Envoyé par SofEvans

Je vais donc creuser dans ce sens (les .so, LD_PRELOAD ne me sont pas familier) puis j'essayerai de faire un truc portable et pas dégueulasse.

---

LD_PRELOAD et les fichiers .so sont des mécanismes propres à certains système. Ce n'est donc par nature pas portable, ou plutôt ça a une portabilité restreinte à certains systèmes.

Mais ça n'en reste pas moins fort utile et pratique.

Citation:

---

Envoyé par SofEvans

Je veux dire, on sait que le type FILE* est une structure opaque qui change en fonction de l'environnement. Si mon programme plante sans qu'un FILE* qui a eu un fopen n'ai pu avoir de fclose, est ce que le fait de liberer les malloc aura la meme action que fclose, a votre avis ?

---

Probablement pas, non. La mémoire alloué à la structure FILE sera peut être libérée, mais le fichier ne sera pas fermé.

Je comprends tout à fait l'utilité de traquer les fuites mémoires, les débordement de buffer, les doubles free, etc. et à ce titre, la supervision mémoire est très utile.
Par contre, je reste, sauf cas particulier, assez dubitatif quant à utiliser un tel mécanisme pour libérer automatiquement les ressources en cas de plantage. Concentre toi sur la correction des erreurs qui provoquent le plantage plutôt qu'essayer de récupérer la situation lorsque le programme à planter.

Merci.
Ceci dis, valgrind n'est il pas plus avancee dans le meme domaine?

Sans doute, mais je suis sous windows et j'ai cru comprendre que valgrind n'etait que sous nux.

Je pense que je vais faire un mix des deux idée.
Désolé gl, mais ca fait très longtemps que je souhaitait avoir un mécanisme caché qui me permettrait de tracer les fuites de mémoire et qui me permettrait de liberer toutes les ressource de manière transparente.

Tu peux commencer par cette ressource, et éventuellement ce programme sous Windows, ca serait déjà une bonne base.
Tu veux réaliser ca pour le système ou juste pour tes applications?

Citation:

---

Envoyé par SofEvans

Sans doute, mais je suis sous windows et j'ai cru comprendre que valgrind n'etait que sous nux.

---

Malheureusement, LD_PRELOAD c'est aussi du Linux (ou du POSIX j'ai un doute). Pas du Windows.

Je ne connais pas les mécanismes similaires sous Windows.