Le mardi 6 janvier, Xavier Bestel a écrit :
> Tout d'abord, il est normal qu'un core aie des trous: il représente
> l'image de la mémoire vue par le process à un moment donné. La carte
> mémoire n'est pas continue sous linux: le code de l'exécutable est à
> 0x08048000, suivis des mmap() et brk(), les bibliothèques et la mémoire
> partagée à 0x40000000, et la pile sous 0xc0000000 (juste avant le
> kernel). Le comme il y a plein de mémoire "non mappée" entre ces zones,
> elles ne sont pas physiquement écrites dans le fichier. Ça fait des
> trous.
Je ne crois pas que les trous dans le fichier core correspondent à ces
trous dans l'espace adressable. Si c'était le cas les fichiers core
auraient une taille (d'après ls -l) énorme. Or ce n'est pas forcément le
cas : les commandes
ulimit -c unlimited
echo "void _start(void) { *(int *) 0 = 0; }" > crash.c
gcc -c crash.c && ld crash.o -o crash
./crash
me font un fichier core de 12 ko sans trous. Avec
echo "int main(void) { int i=1; return *(int *) 0; }" > crash.c
gcc crash.c -o crash
j'ai un core de 60 ko dont 8 ko de trou. Sa taille allouée est de 56 ko
(52 de données et 4 dans un bloc de pointeurs).
Edgar.
--
Edgar Bonet Maison : 04 76 21 29 16 Bureau : 04 76 88 10 96
3 rue Jean Prévost Mobile : 06 77 19 79 39 Fax : 04 76 88 11 91
38000 Grenoble guilde@??? www.edgar-bonet.org
