SUREVEILLER LES ALLOCATIONS DE MEMOIRE [C]

Commentaire de Nebula le 02/07/2005 19:07:30

Une petite remarque en passant : il serait judicieux de prendre en compte une constante comme NDEBUG (très utilisée sous Visual C++) afin de ne pas inclure le code de vérification dans les programmes finaux, ainsi par exemple :

#ifndef NDEBUG

/* exécutable debug : installer le hook */

#define malloc(size) mwatch_malloc(size, __FILE__, __LINE__)
#define free(ptr) mwatch_free(ptr, __FILE__, __LINE__)

#else

/* rien : malloc et free sont déjà définies, normalement */

#endif

Commentaire de Thaeron le 02/07/2005 21:54:47

Je viens de regarder comment tu avais procédé pour connaître la taille qui est free. Je trouve ta méthode géniale, bravo.

Commentaire de remi1203 le 03/07/2005 17:36:30

Voila ca y est g fais une MAJ avec vos remarques. Si vous en avez d'autre, n'hésitez pas !

Commentaire de Clem le 06/07/2005 11:28:03

j'ai pas testé mais regardé le code, et non malloc n'est pas redéfinit du tout, le seul fichier ou le vrai malloc doit être déjà définit c'est mwatch.c, les autres il ne le sera pas, et donc on peut utiliser les noms malloc, realloc, free, sans problèmes, ce qui justement permet d'insérer un code déjà fait et prévu avec malloc, sans avoir à renomer les malloc en mwatch_malloc.
l'avantage ici c'est qu'il utilise du C et non du C++ (beaucoup de personnes préfères le C au C++, la dessus chacun son avis en fonction des besoin en C/C++ que l'on a), c'est donc compatible avec les deux C, et ici si on ne vérifie pas le heap par les api win32 (aucune api win 32 d'ailleurs si je me trompe, donc compatible unix et linux ?), le heap sera lui même vérifié simplement par le vrai malloc.
En fait les fonctions malloc définies par remi sont une sorte de proxy au malloc, qui va réclamer 4 bits de plus que ceux que l'on demande (sizeof(int)=4) et on va donc stocker dans ces 4 bits, la taille de la mémoire définie, ce qui permet donc de la soustraire lors du l'utilisation de free, je doit avouer c'est très ingénieux^^

Commentaire de Clem le 06/07/2005 11:33:13

je vais encore flooder, mais je vient de voir que tu utilise des int, bon je sais qu'il n'y à pas vraiment de danger, je voit mal quelqu'un alouer plus de 2 Go de ram mais c'est toujours plus propre d'utiliser des size_t ou au moins des unsigned int ;)

Commentaire de remi1203 le 06/07/2005 14:23:48

clem > "je doit avouer c'est très ingénieux^^" MERCI bcp

thaeron > g pas UNIX/Linux mais tu peux m'envoyer ton code pr essayer de trouver le truc qui bug ?

Commentaire de remi1203 le 06/07/2005 23:31:39

thaeron > ben en fait ca doit planter si tu fait un malloc (pas mwatch) avec le free correspondant qui lui est mwatch.
par contre ca doit marcher si tu fais un malloc mwatch suivi d'un free normal (mais la t'as un memory leak de la taille d'un entier a chaque fois que tu fais une allocation)

Commentaire de forest2 le 07/11/2005 18:15:08

c'est toujours moi vous savez je programme sous linux et je faire un apple recursiive qui modifie une valeur d'un tableux de vecteur mais il pas initialise donc comment faire merci....