5 réponses
crabs
Messages postés
908
Date d'inscription
lundi 18 avril 2005
Statut
Membre
Dernière intervention
3 août 2008
507
30 sept. 2005 à 16:21
30 sept. 2005 à 16:21
Salut,
Surement par ce que malloc() et le système d'exploitation ne travaille sur des
pages de 1o.
Essayes le programme suivant :
Et regardes de combien est l'offset.
Sous Linux, noyau 2.4.29 sur un pentium III, le pas est de 16 octets.
Pour info, si tu pouvez donner le type de proc, l'OS et le pas ça m'interesse.
A+, Crabs
Surement par ce que malloc() et le système d'exploitation ne travaille sur des
pages de 1o.
Essayes le programme suivant :
#include <stdlib.h> #include <stdio.h> int main( int argc, char** argv ) { int i ; char* pt ; char* pp ; pp = 0 ; for( i=0; i<5; i++ ) { pt = malloc( 1 ) ; printf( "%d : %X %d\n", i, pt, pt-pp ) ; pp=pt ; } return 0 ; }
Et regardes de combien est l'offset.
Sous Linux, noyau 2.4.29 sur un pentium III, le pas est de 16 octets.
Pour info, si tu pouvez donner le type de proc, l'OS et le pas ça m'interesse.
A+, Crabs
obeexpl@lasal:/interfaces/obelix/in/tmp/ysa # prog2 tyty
0 : 400030D8 1073754328
1 : 40005100 8232
2 : 40005110 16
3 : 40005120 16
4 : 40005130 16
je suis sur HPUX mais je comprend rien !!!
0 : 400030D8 1073754328
1 : 40005100 8232
2 : 40005110 16
3 : 40005120 16
4 : 40005130 16
je suis sur HPUX mais je comprend rien !!!
je crois avoir compris, dis moi si je me trompe...
la machine libère un expase mémoire par tranche de 16 octets.
je demande 6* sizeof(char), c'est à dire qu'il alloue 12 octets. Comme il procède par tranche de 16, il alloue en réalité 16 octets. Ce qui signifie que je peux encore caser 2 caractères de plus...le 7eme caractere + le caractere de fin de ligne \0
c'est ça ?
la machine libère un expase mémoire par tranche de 16 octets.
je demande 6* sizeof(char), c'est à dire qu'il alloue 12 octets. Comme il procède par tranche de 16, il alloue en réalité 16 octets. Ce qui signifie que je peux encore caser 2 caractères de plus...le 7eme caractere + le caractere de fin de ligne \0
c'est ça ?
crabs
Messages postés
908
Date d'inscription
lundi 18 avril 2005
Statut
Membre
Dernière intervention
3 août 2008
507
30 sept. 2005 à 20:57
30 sept. 2005 à 20:57
Re-
y a un peu de ça, mais normalement un char c'est un octet.
En réalité, les malloc ont des pas minimum en adresse multiple de 16 dont
n octets nécessaires à la gestion de la mémoire dynamique (les free en autre).
Sous Linux en noyau 2.4, le système est en multiple de 16 et les 4 dernièrs
octect servent à la gestion.
Sous HPUX en processeur 64bits, il lui faut 8o de gestion.
Donc tu alloues jusqu'à 7 o -> tu obtiens 16o : 8o utile + 8o de gestion
Tu écris une chaine de 7c -> tu remplis les 8o car il utilise le dernier
caractère pour le '\0`
Tu écris une chaine de 8c -> tu remplis 9o et tu débordes sur la zone de
gestion => l'OS est perdu => plante du programme.
Tu peux essayer le petits prog avec à la place de malloc(1), malloc(8),
malloc(13), etc...
Par contre HPUX, à une gestion bizarre du premier malloc.
y a un peu de ça, mais normalement un char c'est un octet.
En réalité, les malloc ont des pas minimum en adresse multiple de 16 dont
n octets nécessaires à la gestion de la mémoire dynamique (les free en autre).
Sous Linux en noyau 2.4, le système est en multiple de 16 et les 4 dernièrs
octect servent à la gestion.
Sous HPUX en processeur 64bits, il lui faut 8o de gestion.
Donc tu alloues jusqu'à 7 o -> tu obtiens 16o : 8o utile + 8o de gestion
Tu écris une chaine de 7c -> tu remplis les 8o car il utilise le dernier
caractère pour le '\0`
Tu écris une chaine de 8c -> tu remplis 9o et tu débordes sur la zone de
gestion => l'OS est perdu => plante du programme.
Tu peux essayer le petits prog avec à la place de malloc(1), malloc(8),
malloc(13), etc...
Par contre HPUX, à une gestion bizarre du premier malloc.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question