Librairie pour éviter les fuites memoires

Soyez le premier à donner votre avis sur cette source.

Vue 9 665 fois - Téléchargée 537 fois

Description

Lorsqu'on utilise fréquemment la fonction malloc() pour allouer de la mémoire, il peut arriver que l'on oublie de faire un free() ensuite. Dans ce cas là, le programme continue sans nous avertir. Cela peut-être très gênant parfois, car ce genre d'erreur ne se voit pas facilement.

j'ai été inspiré par les sources de Jcdjcd (ses fichiers util.h et util.c).

J'ai essayé de rendre l'utilisation de ce code le + simple possible.

attention: IL FAUT COMPILER LE PROGRAMME EN MODE DEBUG POUR VOIR LE RESULTAT

- sous gcc en utilisant la commande :

"gcc -D_DEBUG -o ./Prog ./test.c ./debug.c"

- Sous visual en sélectionnant le mode DEBUG et non RELEASE

Source / Exemple :


// petit code avec des erreurs de malloc

#include <stdio.h>
#include <stdlib.h>
#include "debug.h"

int main()
{
	int* var = NULL;
	int* var2 = NULL;
	int* var3 = NULL;

	var = (int*) malloc(sizeof(int));
	
	var2 = (int*) malloc(sizeof(int));

	// on alloue de la memoire plusieurs fois pour var3...
	var3 = (int*) malloc(3*sizeof(int));
	var3 = (int*) malloc(4*sizeof(int));

	free(var);
	free(var);
	// on oublie volontairement de liberer la memoire pour var2 et var3...

	_closedebug();
	
	return 0;
}

Conclusion :


Le résultat lorsqu'on compile en mode debug est l'apparition d'un fichier "log.txt" qui contient les erreurs de malloc().

Par exemple pour le source montré plus haut :
                          • FICHIER LOG.TXT *************


test.c(19): liberation d'un pointeur deja nul
test.c(13): pointeur non libere (adresse: 0x6020c0, nombre d'octets: 4)
test.c(15): pointeur non libere (adresse: 0x602170, nombre d'octets: 12)
test.c(16): pointeur non libere (adresse: 0x602220, nombre d'octets: 16)


J'aimerais ajouter des tas d'autres test, mais avant je voudrais bien avoir votre avis sur la façon dont c'est programmé.
Pour rendre l'utilisation facile, j'ai du faire des choses un peu limites. Donc j'aimerais bien connaître votre opinion.

Ah oui, j'ai pas mal commenté le fichier debug.c
Pensez vous qu'il y a trop de commentaires, que c'est bien ? Ou qu'ils sont mal placés ?
J'essai d'apprendre à commenter un source, mais je sais pas trop comment il faut s'y prendre pour le faire bien.

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

Messages postés
1
Date d'inscription
mercredi 2 juillet 2008
Statut
Membre
Dernière intervention
17 juillet 2008

Salut,
A propos des commentaires, évite de mettre des commentaires c++ " // " dans du code que tu compileras en c.

Certains compilos (le st20cc il me semble) peuvent générer des erreurs !
Les seuls commentaires possibles en C sont " /* */ "

A+
Messages postés
246
Date d'inscription
dimanche 2 juin 2002
Statut
Membre
Dernière intervention
11 septembre 2016
1
le programme gdb sous linux peut t'avertir des fuites mémoires.
C'est assez simple à utiliser pour ça il me semble.
Messages postés
8
Date d'inscription
mardi 28 novembre 2006
Statut
Membre
Dernière intervention
3 mars 2008

Il y a t-il le même outil pour un programme C++ (avec les fuites de mémoires occasionnées par les appels à new sans le delete correspondant.)
Je sais que sous Visual C++ il existe des fonctions déclarées dans ctrdgb.h qui vérifie les opérations effectuées avec le tas et détectent les fuites de mémoire. Mais est-il possible d'utiliser ses mêmes fonctions sous l'environnement Linux ? ou peut-il y avoir des librairies similaires que l'on peut utiliser sous linux ?
Messages postés
49
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
16 juillet 2008

code très pratique et à utiliser dans tous ses programmes ! 10/10
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
oui c'est juste...
en fait moi dans mes libraries, la variable <var> aurait ete mis a NULL pour montrer que le pointeur n'est plus valide
Afficher les 9 commentaires

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.