mon realloc perso

**Jean-Marc.Bourguet** · 27/10/2006, 11h48

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.

**gdpasmini** · 27/10/2006, 11h59

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...

**Franck.H** · 27/10/2006, 12h04

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**Emmanuel Delahaye** · 27/10/2006, 12h17

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.

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...

**InOCamlWeTrust** · 27/10/2006, 13h41

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

**Emmanuel Delahaye** · 27/10/2006, 13h45

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

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.

**InOCamlWeTrust** · 27/10/2006, 13h51

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

Merci quand même !

**InOCamlWeTrust** · 27/10/2006, 13h55

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 !

**Jean-Marc.Bourguet** · 27/10/2006, 14h19

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.

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.

**gdpasmini** · 27/10/2006, 14h38

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 !

**Jean-Marc.Bourguet** · 27/10/2006, 14h48

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.

**Foobar1329** · 27/10/2006, 14h53

Hello,

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

**gdpasmini** · 27/10/2006, 15h57

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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;
}

**Emmanuel Delahaye** · 27/10/2006, 16h06

Envoyé par gdpasmini

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

Ca, ce n'était pas nécessaire

. Disons que tu voulais dire 'la taille des objets pointés'.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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;
}

**gdpasmini** · 27/10/2006, 16h52

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 ?

**Emmanuel Delahaye** · 27/10/2006, 17h11

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

**gdpasmini** · 27/10/2006, 17h16

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...

**Emmanuel Delahaye** · 27/10/2006, 17h22

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...

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...)

**gdpasmini** · 27/10/2006, 17h27

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 ?

**Emmanuel Delahaye** · 27/10/2006, 18h05

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.

mon realloc perso

Réseau C

Discussions similaires

Partager

Partager