Structure des variables en m�moire

Bonjour � tous,
Question un peu vague, mais la moindre petite information sera plus que bienvenue.
J'aimerais savoir comment sont structur�s les blocs de m�moire alou�s dynamiquement.
Un petit exemple vaut mieux etc...

Sous windows, �xecutons le code suivant :

Code:

---

1 2 3 4 5 6 7 8

#include <string.h>   int main(int *argc, char **argv) { char *Test = new char[0xF]; strcpy(Test, "aaaabbbbccccdddd"); }

---

Au d�buguage on note que Test = 0x00430090.

On effectue un dump de la m�moire aux alentours de cette adresse :
(C'est pas beau, mais sans police � chasse fixe, c'est illisible)

Code:

---

1 2 3 4 5 6 7 8 9 10 11

00430080 0F 00 00 00 .... -> J'ai remarqu� que c'�tait la taille du bloc allou� 00430084 01 00 00 00 .... -> Keskec� ? 00430088 29 00 00 00 )... -> What ? 0043008C FD FD FD FD ���� -> C'est quoi ? 00430090 61 61 61 61 aaaa -------------------- 00430094 62 62 62 62 bbbb Voil� le bloc allou� 00430098 63 63 63 63 cccc 0043009C 64 64 64 64 dddd --------------------- 004300A0 00 FD FD 00 .��. -> ????? 004300A4 00 00 00 00 ....

---

De plus, est-ce que cette organisation change en fonction du syst�me d'exploitation, de l'architecture, du language utilis� ou du temps qu'il fait dehors ?

En vous remerciant par avance, vous avez un tr�s beau forum ;)

Je n'ai aucune id�e de la r�ponse � ta question, mais pourquoi diable veux-tu savoir �a ?

Petite suggestion tout de m�me : je pense que �a d�pend de l'environnement ; peut-�tre m�me que certains compilos ajoutent des informations pour faciliter le d�bogage et la d�tection des corruptions de m�moire.

Les structures employ�es par les allocateurs peuvent varier beaucoup. Pas tellement en fonction de l'architecture (qui va g�n�ralement imposer peu en plus des contraintes d'alignement). Les langages peuvent jouer un role. Ce qui va jouer un grand role c'est l'algo d'allocation utilis�. Certains compilateurs sont fournis avec deux ou trois allocateurs ayant des caract�ristiques diff�rentes.

Je n'ai aucune id�e de ce qui est utile dans celui que tu montres.

Il doit surement il y avoir des "magic numbers" pour v�rifier l'int�griter des buffers. car en Release ( sous Win on obtiens pas les m�me valeurs )

Code:

---

1 2 3

0x00000000 : 63 2E 65 78 65 00 00 00 00 00 00 00 03 00 04 00 c.exe........... 0x00000010 : E2 01 09 00 61 61 61 61 62 62 62 62 63 63 63 63 â...aaaabbbbcccc 0x00000020 : 64 64 64

---

Iop,

Citation:

---

Envoy� par Co_Co

Bonjour � tous,
Question un peu vague, mais la moindre petite information sera plus que bienvenue.
J'aimerais savoir comment sont structur�s les blocs de m�moire alou�s dynamiquement.
Un petit exemple vaut mieux etc...

Sous windows, �xecutons le code suivant :

Code:

---

1 2 3 4 5 6 7 8

#include <string.h>   int main(int *argc, char **argv) { char *Test = new char[0xF]; strcpy(Test, "aaaabbbbccccdddd"); }

---

---

Je ne vais pas me m�ler � chercher ce que signifient ces valeurs, mais je vois:

- Tu r�serves une m�moire de 0xF = 15 caract�res, dans laquelle tu mets 16 + 1 = 17 caract�res.
Bingo.

- et le delete ?

Tout d'abord, merci pour vos r�ponses.

A Laurent Gomila : Dans le but de cr�er une classe qui simplifie les allocations/d�sallocations, une bonne connaissance du fonctionnement de la gestion de la m�moire m'est n�cessaire.

A droggo : :oops:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include <string.h>   int main(int *argc, char **argv) { char *Test = new char[0x10]; memcpy(Test, "aaaabbbbccccdddd", 0x10); delete Test;   return 0; }

---

Enfin, � Jean Marc Bourguet, merci : en aiguillant mes recherches sur "algorithme allocation m�moire windows" sur google, j'ai pu trouver des choses int�ressantes :
https://www.securinfos.info/jerome/D...loitation.html
http://ivanlef0u.free.fr/?p=26
Plus g�n�rallement en tapant "structure heap windows", on trouve de la doc en rapport.
En ce qui concerne Linux ou FreeBSD, je n'ai pas encore cherch�, mais �a doit surement �tre mieux document� que sous windows. :lol:

Je n'ai pas encore eu le temps d'�tudier tout �a, mais d�j� :

En mode debug :
Le premier mot correspond bien � la taille
Les mots FD FD FD FD qui encadrent le bloc doivent �tre des mots magiques (merci themadmax)
Quand au reste, pour l'instant, ind�termin�s.

En mode release :
Voir les liens plus haut, tout est expliqu�.

Pour commencer, je pense que quand on alloue une zone m�moire, il ne faut surtout pas chercher � savoir ce qu'il y a autour. Un appel � malloc(size) renvoit une zone libre et utilisable de la bonne taille qu'on peut lib�rer avec free() est tout ce qu'il faut savoir.

Sinon, pour r�pondre � la question ca d�pend de l'impl�mentation utilis�e des librairies standard, c'est � dire: du compilateur (y compris sa version), et de certains param�tres de compilation (debug, release,...), mais aussi du syst�me...

En g�n�ral, les fonctions syst�me sont:

Code:

---

1 2 3

void* system_alloc(size_t length) void system_free(void* ptr, size_t length);

---

Il est donc clair qu'un appel � free(ptr) doit pouvoir retrouver la taille du bloc m�moire. La taille est presque toujours pr�sente autour du bloc allou�.

C'est bien pour cette raison que le code qui d�salloue de la m�moire DOIT �tre celui qui l'alloue. Principalement pour �tre sur que les m�mes fonctions sont utilis�es.
En C++ c'est encore pire, puisqu'on peut red�finir le new et le delete par classe.


Voici une impl�mentation possible:

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

#ifdef _DEBUG #define malloc(size) malloc_debug(size,__FILE__,__LINE__) #define free(ptr) free_debug(ptr) #else #define malloc(size) malloc_release(size) #define free(ptr) free_release(ptr) #endif   struct memory_header { memory_header* prevAllocated; memory_header* nextAllocated; size_t size; const char* file; int line;   };   static memory_header* firstAllocated = 0; static memory_header* lastAllocated = 0;   void* malloc_debug(size_t size, const char* file, int line) { size_t finalsize = size + sizeof(memory_header); memory_header* allocated = (memory_header*)system_allocation(finalsize); if (allocated->prevAllocated = lastAllocated) lastAllocated->nextAllocated = allocated; else firstAllocated = allocated; lastAllocated = allocated; allocated->nextAllocated = 0; allocated->size = size; allocated->file = file; allocated->line = line; return ++allocated; }   void free_debug(void* ptr) { memory_header* hdr = ((memory_header*)ptr) - 1; if (hdr->nextAllocated) hdr->nextAllocated->prevAllocated = hdr->prevAllocated; else lastAllocated = hdr->prevAllocated; if (hdr->prevAllocated) hdr->prevAllocated->nextAllocated = hdr->nextAllocated; else firstAllocated = hdr->nextAllocated; size_t finalsize = hdr->size + sizeof(memory_header); system_free(hdr,finalsize); }

---

Et voil�... � tout moment je peux savoir qui (quel code) a allou� quoi...

Citation:

---

Voici une impl�mentation possible:

---

Ce n'est pas du tout garanti de marcher, �a peut parfaitement violer les contraintes d'alignement.