Bonjour,
 
J'ai un DM de réseau à faire en C, avec une partie du code qui est fournie par les enseignants.
Je suis loin d'avoir fini, mais j'ai déjà testé quelques fonctions, et j'observe une énorme consommation mémoire (conky me dit 50% de la RAM, j'ai 4GB de RAM). C'est beaucoup plus haut de ce à quoi je m'attendais (le programme ouvre deux fichiers de 2MB avec fopen, fait plusieurs allocations de moins de 100B, il y a aussi plusieurs mutex et sockets).
 
Je cherche donc un moyen de connaître précisément par quelle(s) variable(s) sont accessibles ces grandes quantités de mémoire allouée, et/ou savoir à quel endroit du code c'est alloué. Est-ce possible ?
 
Remarque : j'ai aussi ce message de valgrind, qui est lié je pense : ==3936== Warning: set address range perms: large range [0x3959d040, 0x5959d040) (undefined)
 
Tom

Bonjour,

Par n'importe quelle variable, car en c, on peut accéder non seulement au contenu d'une variable (x = a;), mais aussi au contenu pointé par le contenu d'une variable (x = *a;)

Il faut repérer les lignes contenant des malloc(), calloc(), ou realloc(). Il est possible que l'allocation se fasse dans des parties dont vous n'avez pas le code source, auquel cas, c'est presque impossible, à moins d'utiliser un debugger et de mettre un watch sur une zone mémoire.
 
De toutes manières, il n'y a pas lieu de s'inquiéter. Les applications prennent parfois beaucoup de mémoire sans qu'il y ait de fuite mémoire. S'il y a une fuite mémoire, c'est autre chose. Relisez attentivement votre code pour voir s'il n'y en aurait pas. Les causes principales de fuite mémoire en C sont :  
 
- une absence de nul binaire à la fin d'une chaine de caractère alors qu'on utilise l'une des fonctions de manipulation de chaine de caractères,  
- une dimension trop petite d'une zone, par exemple, si on n'a oublié de compter la place pour un nul en fin de chaine,
- une boucle for() qui va trop loin, un appel récursif qui ne s'arrête pas,  
- une absence d'initialisation, par exemple en pensant qu'une zone est à zéro au début, alors qu'elle ne l'est pas, où qu'un pointeur sera remis à zéro après un free() alors que ce n'est pas le cas.
 
Pour infos, les adresses mémoires sont susceptibles de changer d'un lancement du programme à un autre. C'est normal. C'est le système d'exploitation qui voit les emplacements libres, et même qui évitent de donner toujours les mêmes emplacements pour des raisons de sécurité.

Merci pour votre réponse.
 
Après avoir mis un printf après chaque malloc, j'ai finalement trouvé l'origine du problème : une mauvaise variable donnée à malloc pour spécifier la taille à allouer, résultant en quatre allocations de 536870912 octets (d'où les 2GB de RAM utilisés).
 
Pour info, la maccro suivante évite d'ajouter les printf à la main :

 
Problème résolu  

Merci pour le retour.
Et l'astuce du #define est intéressante (edit : mais il faut que toutes les lignes de malloc soient simples, parce que si on a une ligne if ((ptr = malloc(x)) != null), alors l'insertion du printf va empêcher la compilation).