mon realloc perso

Version imprimable

Voir 40 message(s) de cette discussion en une page

mon realloc perso

Bonjour a tous !

Dans la famille redifinition de fonction je voudrais le realloc !

J'ai fais ce code :
Code:

1 2 3 4 5 6 7 8 void *Monrealloc(void *ptr, size_t size) { void * monNouveauPointeur = Monmalloc(size); memcpy(monNouveauPointeur, ptr, size); Monfree(ptr); return (void *)monNouveauPointeur; }
Ca a l'air de marcher mais est ce que le realloc fonctionne comme ceci ?

La raison de cette redeclaration est dû a des pb memoires que j'observe sur un system embarqué. En effet, il arrive parfois que la libération d'un pointeur null fasse planter la machine... Est ce normal ?

27/10/2006, 09h51
Emmanuel Delahaye
Citation:

Envoyé par gdpasmini

Ca a l'air de marcher mais est ce que le realloc fonctionne comme ceci ?

Pas tout à fait. Si le pointeur d'initial est NULL, le comportement doit être défini (ce qui n'est pas le cas ici).
Code:

1 2 3 4 5 6 if (ptr != NULL) { memcpy(monNouveauPointeur, ptr, size); } ...
Note : Le cast à la fin est inutile :

Code:

return monNouveauPointeur;

Citation:

La raison de cette redeclaration

Tu veux sans doute dire redéfinition...

Citation:

est dû a des pb memoires que j'observe sur un system embarqué. En effet, il arrive parfois que la libération d'un pointeur null fasse planter la machine... Est ce normal ?

Non. Il doit y avoir un autre problème, genre débordement de bloc alloué ou utilisation de pointeur non initialisé ou NULL...
27/10/2006, 10h00
Jean-Marc.Bourguet

Il faut copier une quantité de données correspondant à ce qui était alloué précédemment, pas ce qui est nouvellement alloué.
27/10/2006, 10h11
Médinoc

Pour être précis, il faut copier la plus petite des deux tailles (oui, on peut se servir de realloc() pour réduire un espace alloué).

Et aussi, une implication plus profonde de Monrealloc() dans ta gestion du tas pourrait permettre de changer la taille "sur place" s'il n'y a rien qui gène (100% de réussite pour un rétrécissement)...
27/10/2006, 10h35
Franck.H
Citation:
Envoyé par Emmanuel Delahaye

Pas tout à fait. Si le pointeur d'initial est NULL, le comportement doit être défini (ce qui n'est pas le cas ici).

Code:

1 2 3 4 5 6 if (ptr != NULL) { memcpy(monNouveauPointeur, ptr, size); } ...
Il me semble que si le pointeur passé en paramètre est NULL, realloc se comporte comme malloc. Cela peut varier d'une implémentation à une autre ?
27/10/2006, 10h40
gdpasmini
ok merci beaucoup.. mais pour copier la plus petite des deux tailles, il faut connaitre la taille précédement allouée or lors du realloc on a plus accès a cette information .. Si ?

D'autre part, lors de mes tests, un free fait reellement planter ma machine..
J'ai donc rajouté une protection :
Code:

1 2 3 4 5 6 7 8 Monfree(void * ptr) { if(ptr == NULL) return; else free(ptr); }
Depuis, ca plante moin...
27/10/2006, 10h41
Médinoc

C'est anormal, il me semble bien que la norme dit que free(NULL) doit "échouer" silencieusement...
(à l'inverse de fclose(NULL) qui est indéfini)
27/10/2006, 10h45
gdpasmini

Je ne comprends pas non plus pk si un pointeur n'est pas initialisé a NULL, il peut planté lors de l'allocation...

D'autre part, comment obtenir la taille précédement allouée ?
27/10/2006, 10h47
Emmanuel Delahaye

Citation:

Envoyé par Jean-Marc.Bourguet

Il faut copier une quantité de données correspondant à ce qui était alloué précédemment, pas ce qui est nouvellement alloué.

:oops: Exact, sinon, on lit dans une zone en partie indéterminée.

Problème, on ne connait pas cette taille, donc on est cuit, on ne peut pas écrire son realloc()...

Affaire réglée.
27/10/2006, 10h48
Emmanuel Delahaye

Citation:

Envoyé par Franck.H

Il me semble que si le pointeur passé en paramètre est NULL, realloc se comporte comme malloc.

Ben oui, d'où la protection de memcpy() par le if ...

Citation:

Cela peut varier d'une implémentation à une autre ?

Pas si ces implémentations sont conformes au C standard.
27/10/2006, 10h50
Emmanuel Delahaye

Citation:

Envoyé par Franck.H

Il me semble que si le pointeur passé en paramètre est NULL, realloc se comporte comme malloc. Cela peut varier d'une implémentation à une autre ?

Ben oui, d'où la protection de memcpy()...

De toutes façons, comme l'a fait remarqué Jean Marc, on ne peut pas créeer son realloc() [1]. Affaire classée...

-----------------------
[1] à moins de passer un paramètre en plus : 'ancienne_taille'...
27/10/2006, 10h50
gdpasmini

on ne peut pas ecrire son propre realloc ?

La protection du memcpy ne le permet il pas ?
27/10/2006, 10h52
Médinoc

Citation:

Envoyé par Emmanuel Delahaye

Problème, on ne connait pas cette taille, donc on est cuit, on ne peut pas écrire son realloc()...

Affaire réglée.

Pour être précis, je dirais qu'on ne peut pas écrire de realloc() à un niveau supérieur à celui des malloc() et free() : Le realloc doit au moins être au même niveau, voire à un niveau inférieur.
27/10/2006, 10h55
gdpasmini

ola, dsl mai je comprends pas l'histoire des niveaux...
27/10/2006, 10h55
Emmanuel Delahaye
Citation:

Envoyé par gdpasmini

ok merci beaucoup.. mais pour copier la plus petite des deux tailles, il faut connaitre la taille précédement allouée or lors du realloc on a plus accès a cette information .. Si ?

Non. D'où problème. A part passer l'info sous la forme d'un paramètre, je ne vois pas d'issue.
Citation:
D'autre part, lors de mes tests, un free fait reellement planter ma machine..
J'ai donc rajouté une protection :

Code:

1 2 3 4 5 6 7 8 Monfree(void * ptr) { if(ptr == NULL) return; else free(ptr); }

Depuis, ca plante moin...
Ca n'a strictement rien résolu du tout.

Déjà cité, mais tellement à-propos :

"Ce n'est pas en cassant le thermomètre qu'on guéri le malade."
27/10/2006, 10h58
gdpasmini

pourtant je vous assure qu'en mettant un printf avant et apres le free, je vois clairement qu'il ne sort jamais de mon free..
27/10/2006, 11h00
Emmanuel Delahaye
Citation:

Envoyé par gdpasmini

Je ne comprends pas non plus pk si un pointeur n'est pas initialisé a NULL, il peut planté lors de l'allocation...

8O 8O 8O T'as lu ça où ?
Code:

1 2 3 4 T *p; p = malloc(...);
et

Code:

T *p = malloc(...);

sont parfaitement valides.

Citation:

D'autre part, comment obtenir la taille précédement allouée ?

Il faut s'en souvenir. (une variable, par exemple, ou une structure qui regroupe le pointeur et la taille allouée).
27/10/2006, 11h14
Emmanuel Delahaye

Citation:

Envoyé par gdpasmini

pourtant je vous assure qu'en mettant un printf avant et apres le free, je vois clairement qu'il ne sort jamais de mon free..

:boulet: On se tue à te dire que c'est la conséquence d'un problème qui c'est passé avant, comme un débordement de mémoire, ce qui a détruit le gestionnaire de mémoire allouée, d'où le crash. Isole ton code à coup de #if 0 #endif jusqu'à trouver le fautif...
27/10/2006, 11h22
Jean-Marc.Bourguet

Citation:

Envoyé par Emmanuel Delahaye

Problème, on ne connait pas cette taille, donc on est cuit, on ne peut pas écrire son realloc()...

Si on écrit les fonctions malloc, realloc et free, ce qui a l'air d'être le cas de l'OP, on peut stocker cette taille quelque part de sorte qu'on la retrouve après. On en a de toute manière besoin aussi pour le free.

Une technique est de faire précéder les blocs de leur taille.
27/10/2006, 11h29
Emmanuel Delahaye

Citation:

Envoyé par Jean-Marc.Bourguet

Si on écrit les fonctions malloc, realloc et free, ce qui a l'air d'être le cas de l'OP...

Ca m'a tout l'air d'être de simples wrappers... Pour le reste, OK. attention aux problèmes d'alignement !
27/10/2006, 11h48
Jean-Marc.Bourguet

Citation:

Envoyé par Emmanuel Delahaye

Ca m'a tout l'air d'être de simples wrappers... Pour le reste, OK. attention au problèmes d'alignement !

Si tu es en train d'écrire des remplacements pour malloc et cie, que ce soit des wrappers ou pas, tu as intérêt à faire attention à l'alignement.
27/10/2006, 11h59
gdpasmini

dsl pour cette question mais comment isole ton le code ? le #if 0 #endif je ne connais pas...

par contre pour le realloc, jai testé des fonctions avec des listes chainées.. Lors d'un malloc, je créé une nouvelle structure contenant le pointeur et la taille et lors du free, je parcours la liste pour chercher le pointeur en question et ainsi récupérer la taille..

Ca fonctionne et me permet de conaitre la taille memoire totale allouée a chaque appel de malloc..

D'autre part, le debordement m'étonne vraiment, meme si je ne doute pas de votre avis, car ce bug intervient tres aleatoirement... et parfois au tout debut du programme...
27/10/2006, 12h04
Franck.H
Citation:

Envoyé par gdpasmini

dsl pour cette question mais comment isole ton le code ? le #if 0 #endif je ne connais pas...

Ce n'est rien d'autre que tu pré-processeur:
Code:

1 2 3 4 #if 0 /* code a ne pas executer par exemple. */ #endif
Tu entoures un code que tu ne veux pas exécuter par exemple, comme tu le fairais en le mettant en commentaire mais cette façon est bien mieux ;)
27/10/2006, 12h17
Emmanuel Delahaye

Citation:

Envoyé par gdpasmini

par contre pour le realloc, jai testé des fonctions avec des listes chainées.. Lors d'un malloc, je créé une nouvelle structure contenant le pointeur et la taille et lors du free, je parcours la liste pour chercher le pointeur en question et ainsi récupérer la taille..

OK.

Citation:

D'autre part, le debordement m'étonne vraiment, meme si je ne doute pas de votre avis, car ce bug intervient tres aleatoirement... et parfois au tout debut du programme...

Voilà qui devrait accelérer les recherches...

Citation:

Envoyé par Jean-Marc.Bourguet

Si tu es en train d'écrire des remplacements pour malloc et cie, que ce soit des wrappers ou pas, tu as intérêt à faire attention à l'alignement.

Exact. La documentation de la GLibC spécifie même, si je ne me trompe pas, que les adresses retournées par malloc sont toujours alignées sur des frontières de mots mémoire. Dans la doc, il précisent la valeur 8 (8 caractères, j'entends), de mémoire.

Une petite question : j'ai déjà écrit ma propre version de malloc et free, grâce à un algorithme entièrement personnel, et qui donne d'excellents résultats (aussi bons, voire même meilleurs dans le cas moyen que les fonctions de la GLibC... mais pas aussi paramètrables, pour l'instant). Quelle est le type à choisir pour forcer l'alignement ? Plus précisément : on suppose que l'on alloue par blocs, de taille fixée déterminée par le type contenant le cartouche et le type forçant l'alignement mémoire. Classiquement :
Code:

1 2 3 4 5 6 7 8 9 /* cartouche_t est le type des cartouches */ typedef cartouche_t; /* align_t est le type forçant l'alignement */ typedef align_t; /* type des blocs : on prend une union pour forcer l'alignement mémoire */ union { align_t align; cartouche_t cartouche } bloc_t;
Le problème est qu'il est écrit dans le K&R que le type permettant de forcer l'alignement est dépendant de l'implantation. Sur mon ordi, j'utilise le type long, mais le K&R fait aussi référence au type long double (qui a de fortes chances d'être sur 80 bits avec un x86), alors qu'il me faudrait un type portable...

Connaissez-vous un type défini dans un .h standard, ou autre, permettant de forcer l'alignement, de sorte à être un maximum portable ?

27/10/2006, 13h45
Emmanuel Delahaye

Citation:

Envoyé par InOCamlWeTrust

Connaissez-vous un type défini dans un .h standard, ou autre, permettant de forcer l'alignement, de sorte à être un maximum portable ?

Je pense que l'idée, c'est de prendre le type simple le plus grand. Pour ça, il faut étudier la doc de chaque compilateur. Ca ne peut pas être portable.

Cependant, il est possible qu'en C99, il existe un type portable qui réponde à la question. Mais C99 n'est pas disponible partout et Microsoft et Borland semblent l'ignorer...

Effectivement, dans le très C99 <stdint.h>, on trouve des choses genre

Citation:

7.18.1.5 Greatest-width integer types
1 The following type designates a signed integer type capable of representing any value of
any signed integer type:
intmax_t
The following type designates an unsigned integer type capable of representing any value
of any unsigned integer type:
uintmax_t
These types are required.
27/10/2006, 13h51
InOCamlWeTrust

Oui, je vois, c'est bien ce que je pensais.

Merci quand même !
27/10/2006, 13h55
InOCamlWeTrust

Citation:

Envoyé par Emmanuel Delahaye

Mais C99 n'est pas disponible partout et Microsoft et Borland semblent l'ignorer...

Ca, c'est très fort, je trouve !
27/10/2006, 14h19
Jean-Marc.Bourguet

Citation:

Envoyé par InOCamlWeTrust

Exact. La documentation de la GLibC spécifie même, si je ne me trompe pas, que les adresses retournées par malloc sont toujours alignées sur des frontières de mots mémoire.

La norme impose à malloc de retourner un pointeur valable pour le type le plus contraint.

Citation:

Connaissez-vous un type défini dans un .h standard, ou autre, permettant de forcer l'alignement, de sorte à être un maximum portable ?

En C, il n'y a pas moyen. En C++ il y a un template alignment_of dans TR1 et il devrait être repris dans la future norme.

En attendant, il faut te bâtir une union avec tous les types dedans... En C90, il est raisonnable de te limiter à long, void*, long double avec le risque qu'une extension (par exemple long long) casse ce que tu as fais. En C99 intmax_t, long double, void* devrait suffire avec moins de risques qu'une extension casse.
27/10/2006, 14h38
gdpasmini

C'est une piste, oui et non, car a la base, la fonction dans laquelle le programme plante est une fonction d'une librairie open source stable et non soumis au bug... a priori..

Seulement, je l'utilise dans des interuptions et non dans des threads que cette librairie utilise normalement..

On peut donc penser, si l'on fait confiance en cette librairie que le bug est produit par une autre interuption pendant l'execution du code mais j'ai vérifié et ca n'est pas le cas..

D'autre part, meme si il existe d'autres plantages etranges, les plus fréquents ont lieu dans une fonction particulière de cette librairie !!

Le jeu de piste dure depuis plusieurs jours deja et je n'en vois pas le bout !
27/10/2006, 14h48
Jean-Marc.Bourguet

Le bug le plus difficile a trouver sur lequel j'ai jamais travaillé avait lieu quand une interruption non masquable arrivait pendant qu'une autre interruption consommait son maximum de pile et que cette interruption interrompait le programme principal alors qu'il était aussi a son maximum de pile. Alors la pile dépassait de 1 octet sa zone allouée et écrasait des donc des données. Un bon moment après l'interruption le système -- c'était dans un système embarqué programmé totalement en assembleur, il y avait une dizaine de processeurs de 3 modèles diffétents -- partait dans les choux... Il m'a fallu 3 semaines à temps plein pour trouver la source du problème. D'autres y travaillaient depuis des mois (mais à temps partiel). Le problème ne s'est en particulier jamais produit sur une simulation du système qui a tourné pendant tout ce temps.
27/10/2006, 14h53
Foobar1329

Hello,

Citation:

Envoyé par Médinoc

C'est anormal, il me semble bien que la norme dit que free(NULL) doit "échouer" silencieusement...
(à l'inverse de fclose(NULL) qui est indéfini)

Oui, c'est anormal par rapport à la norme. Pour être précis, free(NULL) ne doit rien faire du tout, d'après §7.20.3.2 de la n1124.

Maintenant, il a toujours certaines implémentations qui violent la norme sur ce point et qui plantent avec free(NULL), soit pour raisons historiques, soit pour des raisons de débogage. Il faut l'avis des "vieux" pour éclaircir ce point.

A+
Foobar1329

Bon voila ce que j'ai fai pour enregistrer la taille de mes pointeurs. A priori, je ne vois pas de problemes.. Mais j'ai peur des boucles infinies..

J'ai trop relu le code pour voir un eventuel bug.. Est ce que quelqu'un voit un pb dans ce code ?

Si c bon, ca pourra resservir a kkun..

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
 
 
typedef struct mesMalloc{
	size_t size;
	void * ptr;
	struct mesMalloc * pSuivant;
	struct mesMalloc * pPrecedent;
}p_mesMalloc;
 
p_mesMalloc * myFirstMalloc = NULL;
 
p_mesMalloc * rechercheDernierPointeur(void)
{
	p_mesMalloc *pCurrentMalloc = myFirstMalloc;
 
	if(pCurrentMalloc == NULL)
		return NULL;
	else
	{
		while(pCurrentMalloc->pSuivant != NULL)
		{
 
			pCurrentMalloc = pCurrentMalloc->pSuivant;
		}
		return pCurrentMalloc;
	}
}
 
p_mesMalloc * recherchePointeur(void * ptr)
{
	p_mesMalloc *pCurrentMalloc = myFirstMalloc;
 
	if(pCurrentMalloc == NULL)
		return NULL;
	else
	{
		while(ptr != pCurrentMalloc->ptr)
		{
			if(pCurrentMalloc->pSuivant != NULL)
				pCurrentMalloc = pCurrentMalloc->pSuivant;
			else
				return NULL;
		}
 
		return pCurrentMalloc;
	}
}
 
p_mesMalloc * ajoutNouveauMalloc(void * ptr, size_t size)
{
	p_mesMalloc *pCurrentMalloc = myFirstMalloc;
	p_mesMalloc *pNewMalloc = NULL;
 
	pCurrentMalloc = rechercheDernierPointeur();
 
	if(pCurrentMalloc == NULL)
	{
		pCurrentMalloc = (p_mesMalloc *)malloc(sizeof(p_mesMalloc));
		if(pCurrentMalloc == NULL)
			return NULL;
		pCurrentMalloc->ptr = ptr;
		pCurrentMalloc->size = size;
		pCurrentMalloc->pSuivant = NULL;
		pCurrentMalloc->pPrecedent = NULL;
		myFirstMalloc = pCurrentMalloc;
		return pCurrentMalloc;
	}
	else
	{
		pNewMalloc = (p_mesMalloc *)malloc(sizeof(p_mesMalloc));
		pNewMalloc->ptr = ptr;
		pNewMalloc->size = size;
		pNewMalloc->pSuivant = NULL;
		pNewMalloc->pPrecedent = pCurrentMalloc;		
		pCurrentMalloc->pSuivant = pNewMalloc;
		return pNewMalloc;
	}
}
 
int suppressionMalloc(void * ptr)
{
	p_mesMalloc *pCurrentMalloc = myFirstMalloc;
 
	pCurrentMalloc = recherchePointeur(ptr);
 
	if(pCurrentMalloc == NULL)
		return 0;
	else
	{
		if(pCurrentMalloc->pSuivant != NULL && pCurrentMalloc->pPrecedent != NULL)
		{
			pCurrentMalloc->pPrecedent->pSuivant = pCurrentMalloc->pSuivant;
			pCurrentMalloc->pSuivant->pPrecedent = pCurrentMalloc->pPrecedent;
		}
		else if(pCurrentMalloc->pSuivant != NULL && pCurrentMalloc->pPrecedent == NULL)
		{
			pCurrentMalloc->pSuivant->pPrecedent = NULL;
			myFirstMalloc = pCurrentMalloc->pSuivant;
		}
		else if(pCurrentMalloc->pSuivant == NULL && pCurrentMalloc->pPrecedent != NULL)
		{
			pCurrentMalloc->pPrecedent->pSuivant = NULL;
		}
		else if(pCurrentMalloc->pSuivant == NULL && pCurrentMalloc->pPrecedent == NULL)
		{
			myFirstMalloc = NULL;
		}
 
		free(pCurrentMalloc);
 
		return 1;
	}
}
 
int modificationMalloc(void * ptr, size_t size)
{
	p_mesMalloc *pCurrentMalloc = NULL;
 
	pCurrentMalloc = recherchePointeur(ptr);
	if(pCurrentMalloc != NULL)
	{
		pCurrentMalloc->ptr = ptr;
		pCurrentMalloc->size = size;
		return 1;
	}
	else 
		return 0;
}
 
int calculTailleMemoireAllouee(void)
{
	p_mesMalloc *pCurrentMalloc = myFirstMalloc;
	int tailleTotale = 0;
 
	while(pCurrentMalloc != NULL)
	{
		tailleTotale += pCurrentMalloc->size;
		pCurrentMalloc = pCurrentMalloc->pSuivant;
	}
	printf("taille utilisee = %d\n", tailleTotale);
	return tailleTotale;
}

Citation:

Envoyé par gdpasmini

Bon voila ce que j'ai fai pour enregistrer la taille de mes pointeurs.

Ca, ce n'était pas nécessaire :lol: . Disons que tu voulais dire 'la taille des objets pointés'.

Citation:

A priori, je ne vois pas de problemes.. Mais j'ai peur des boucles infinies..

J'ai trop relu le code pour voir un eventuel bug.. Est ce que quelqu'un voit un pb dans ce code ?

J'ai déterminé que les points d'entrée étaient :
Code:

1 2 3 4 5 p_mesMalloc *ajoutNouveauMalloc (void *ptr, size_t size); int suppressionMalloc (void *ptr); int modificationMalloc (void *ptr, size_t size); size_t calculTailleMemoireAllouee (void);
Ca s'utilise comme ça ? :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 #include <assert.h> #include <string.h> #define PERR(e)\ do\ {\ if (e)\ {\ printf ("ERR %d at %s:%d\n", e, __FILE__, __LINE__); \ }\ }\ while (0) int main (void) { char s[20]; p_mesMalloc *p = ajoutNouveauMalloc (s, sizeof s); if (p != NULL) { printf ("Taille allouee = %lu\n", (unsigned long) calculTailleMemoireAllouee ()); assert (p->ptr != NULL); strcpy (p->ptr, "Hello world"); printf ("%s\n", (char *) p->ptr); { int err = suppressionMalloc (p); PERR (err); } } return 0; }

27/10/2006, 16h52
gdpasmini

en fait, moi je pensais l'utiliser directement dans mes propre malloc..

Ainsi a chaque malloc appelé, une nouvelle structure est céée contenant le ptr ainsi que sa taille.

Lors d'un free, la structure est detruite et lors d'un realloc, on modifie la taille et le pointeur.

Ceci permet de connaitre a tout moment la taille allouée par malloc.. en enlevant la taille allouée a chaque structures bien sur..

Ainsi on a egalement acces a la taille allouée a un pointeur particulier.. Ce qui peut servir pour un realloc..

Tu as observé des bugs ? Qu'est ce que tu penses de mon code ?
27/10/2006, 17h11
Emmanuel Delahaye
Citation:

Envoyé par gdpasmini

en fait, moi je pensais l'utiliser directement dans mes propre malloc..

Ainsi a chaque malloc appelé, une nouvelle structure est céée contenant le ptr ainsi que sa taille.

Lors d'un free, la structure est detruite et lors d'un realloc, on modifie la taille et le pointeur.

Ceci permet de connaitre a tout moment la taille allouée par malloc.. en enlevant la taille allouée a chaque structures bien sur..

Ainsi on a egalement acces a la taille allouée a un pointeur particulier.. Ce qui peut servir pour un realloc..

Tu as observé des bugs ? Qu'est ce que tu penses de mon code ?

Apparemment, non. Si j'ai bien compris, tu es en train de faire un traceur de mémoire allouée.

Mais ce qui me heurte, c'est que tu utilises 2 concepts que je trouve choquants :
- la mémoire allouée (il y a un coté 'juge et partie' ou 'récursif' qui ne me plait pas (un instrument de mesure ne doit pas influencer la mesure).
- une liste doublement chainée qui est loin d'être triviale, même si on peut espérer qu'elle s'inspire de code déjà validé.
J'ai moi-même construit un 'traceur de mémoire dynamique' qui est basé sur 2 principes différents :
- une zone de stockage statique fournie par l'application
- le formatage en 'tableau' de cette zone de stockage
- l'utilisation d'apparence standard des fonctions du C. C'est une macro qui redirige les fonctions malloc/free vers les miennes (sys_malloc/sys_mem_free). Le code initial est donc inchangé, la seul contrainte est d'inclure "ed/inc/sysalloc.h" en première ligne de chaque source utilisant malloc/free.
http://emmanuel-delahaye.developpez.com/clib.htm
Module SYSALLOC
27/10/2006, 17h16
gdpasmini

oui je comprends ce que tu veux dire pour le test..
Pour le code, je ne me suis inspiré de rien.. Dou le risque d'erreur.

Sinon pour ton code, c pas mal mais je sais pas si c tres implémentable dans mon system..

D'autant plus que je suis parti pour faire des malloc et des free un peu spéciaux me permettant de reserver une zone memoire en debut d'application et de faire les malloc uniquement dedans...
27/10/2006, 17h22
Emmanuel Delahaye

Citation:

Envoyé par gdpasmini

Sinon pour ton code, c pas mal mais je sais pas si c tres implémentable dans mon system.

C'est très portable et je l'ai utilisé à mort en embarqué (réseaux numériques) où il m'a sauvé la vie plus d'une fois...

Citation:

D'autant plus que je suis parti pour faire des malloc et des free un peu spéciaux me permettant de reserver une zone memoire en debut d'application et de faire les malloc uniquement dedans...

Oui, un pool. J'ai aussi utilisé ce module dans ce genre de situation. J'ai juste modifié les 4 appels de fonction réels (malloc/calloc/realloc/free) en fonction des appels systèmes requis.

Ca m'a aussi sauvé la vie et celle de nos partenaires sur ce coup là. (Quoique je ne sais pas si la SAT existe encore...)
27/10/2006, 17h27
gdpasmini

Alors merci mille fois !

Je vais y jeter oeil mais j'avoue que a premiere vue, ca me semble costaud !

Pour tout dire, je suis debutant et je galere un peu ! lol

Je vais regarder ca de plus pres en essayant de ne pas y passer le we ! Si ca ta sauvé la vie, ca sauvera pe la mienne !

Par contre une quesiton, ce code te permet de créer un pool ou il faut l'impémenter en plus ?
27/10/2006, 18h05
Emmanuel Delahaye

Citation:

Envoyé par gdpasmini

Par contre une quesiton, ce code te permet de créer un pool ou il faut l'impémenter en plus ?

Ca fait 2 questions, donc : non, oui.

C'est uniquement un traceur de mémoire dynamique. C'est à toi d'écrire le pool, mais est-ce bien nécessaire ? Sur tous les systèmes embarqués où j'avais un malloc()/free() opérationnel, je n'ai jamais eu besoin de pool.

Voir 40 message(s) de cette discussion en une page