Salut,
Un petit souci de compréhension avec les bibliothèques partagées.
Normalement, une fois chargée, la bibliothèque a son propre
emplacement mémoire. Si de plus elle est partagée par de nombreux
processus, la bibliothèque reste en place jusqu'à ce que le dernier
processus pointant dessus ne disparaisse.
Prenons l'exemple de la libC, puisqu'on est sûr qu'elle est tout le
temps en mémoire :
# cat /proc/self/maps
55af0014f000-55af00151000 r--p 00000000 08:01 530907
/usr/bin/cat
55af00151000-55af00156000 r-xp 00002000 08:01 530907
/usr/bin/cat
55af00156000-55af00159000 r--p 00007000 08:01 530907
/usr/bin/cat
55af00159000-55af0015a000 r--p 00009000 08:01 530907
/usr/bin/cat
55af0015a000-55af0015b000 rw-p 0000a000 08:01 530907
/usr/bin/cat
55af01db6000-55af01dd7000 rw-p 00000000 00:00 0 [heap]
7fce55bee000-7fce563db000 r--p 00000000 08:01 533170
/usr/lib/locale/locale-archive
7fce563db000-7fce563fd000 r--p 00000000 08:01 527716
/usr/lib/x86_64-linux-gnu/libc-2.31.so
7fce563fd000-7fce56575000 r-xp 00022000 08:01 527716
/usr/lib/x86_64-linux-gnu/libc-2.31.so
7fce56575000-7fce565c3000 r--p 0019a000 08:01 527716
/usr/lib/x86_64-linux-gnu/libc-2.31.so
7fce565c3000-7fce565c7000 r--p 001e7000 08:01 527716
/usr/lib/x86_64-linux-gnu/libc-2.31.so
7fce565c7000-7fce565c9000 rw-p 001eb000 08:01 527716
/usr/lib/x86_64-linux-gnu/libc-2.31.so
7fce565c9000-7fce565cf000 rw-p 00000000 00:00 0
7fce565db000-7fce565fd000 rw-p 00000000 00:00 0
7fce565fd000-7fce565fe000 r--p 00000000 08:01 527712
/usr/lib/x86_64-linux-gnu/ld-2.31.so
7fce565fe000-7fce56621000 r-xp 00001000 08:01 527712
/usr/lib/x86_64-linux-gnu/ld-2.31.so
7fce56621000-7fce56629000 r--p 00024000 08:01 527712
/usr/lib/x86_64-linux-gnu/ld-2.31.so
7fce5662a000-7fce5662b000 r--p 0002c000 08:01 527712
/usr/lib/x86_64-linux-gnu/ld-2.31.so
7fce5662b000-7fce5662c000 rw-p 0002d000 08:01 527712
/usr/lib/x86_64-linux-gnu/ld-2.31.so
7fce5662c000-7fce5662d000 rw-p 00000000 00:00 0
7ffec2974000-7ffec2995000 rw-p 00000000 00:00 0 [stack]
7ffec29f7000-7ffec29fb000 r--p 00000000 00:00 0 [vvar]
7ffec29fb000-7ffec29fd000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0
[vsyscall]
Pas de souci : le découpage du cat renvoie vers la partie statique du
processus, son allocation dynamique puis les bibliothèques liées et
enfin la pile.
Pour y voir plus clair,
# cat /proc/self/maps | grep libc
7f6a8e5a6000-7f6a8e5c8000 r--p 00000000 08:01 527716
/usr/lib/x86_64-linux-gnu/libc-2.31.so
7f6a8e5c8000-7f6a8e740000 r-xp 00022000 08:01 527716
/usr/lib/x86_64-linux-gnu/libc-2.31.so
7f6a8e740000-7f6a8e78e000 r--p 0019a000 08:01 527716
/usr/lib/x86_64-linux-gnu/libc-2.31.so
7f6a8e78e000-7f6a8e792000 r--p 001e7000 08:01 527716
/usr/lib/x86_64-linux-gnu/libc-2.31.so
7f6a8e792000-7f6a8e794000 rw-p 001eb000 08:01 527716
/usr/lib/x86_64-linux-gnu/libc-2.31.so
Patatra... le nouveau processus pointe bien sur la libc comme
attendu... mais sur une autre adresse physique (7fce563db000 vs
7fce563db000)
Une idée d'où je me goure-je ?
Merci
PK
--
|\ _,,,---,,_ Patrice KARATCHENTZEFF
ZZZzz /,`.-'`' -. ;-;;,_ mailto:patrice.karatchentzeff@gmail.com
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_)
