Jan Rychter wrote on Mon, Feb 23, 2004 at 12:37:55PM -0800: > meanwhile maps from a plain boring tcsh process: > > 00984000-00ab7000 r-xp 00000000 03:05 2015243 /lib/tls/libc-2.3.2.so > 00ab7000-00abb000 rw-p 00132000 03:05 2015243 /lib/tls/libc-2.3.2.so > 00abb000-00abd000 rw-p 00000000 00:00 0 > 08047000-08091000 r-xp 00000000 03:05 835662 /bin/tcsh > 08091000-08095000 rw-p 0004a000 03:05 835662 /bin/tcsh > 08095000-080c5000 rw-p 00000000 00:00 0 > 08f7b000-08fc5000 rw-p 00000000 00:00 0 > 49599000-495ae000 r-xp 00000000 03:05 740724 /lib/ld-2.3.2.so > 495ae000-495af000 rw-p 00015000 03:05 740724 /lib/ld-2.3.2.so > 49722000-4972c000 r-xp 00000000 03:05 737358 /lib/libnss_files-2.3.2.so > 4972c000-4972d000 rw-p 0000a000 03:05 737358 /lib/libnss_files-2.3.2.so > 499bc000-499bf000 r-xp 00000000 03:05 737364 /lib/libtermcap.so.2.0.8 > 499bf000-499c0000 rw-p 00002000 03:05 737364 /lib/libtermcap.so.2.0.8 > 49c04000-49c09000 r-xp 00000000 03:05 740729 /lib/libcrypt-2.3.2.so > 49c09000-49c0a000 rw-p 00004000 03:05 740729 /lib/libcrypt-2.3.2.so > 49c0a000-49c31000 rw-p 00000000 00:00 0
These people are just insane. The shared libs used to hang out at 0x4000xxx to 0x4200xxx. Then Redhat 7 comes along and they take up space to 0x4400xxx. Fine, I can move up. And now they come up with new random landgrab? I can see why they do it, because glibc always gives new malloc space below the shared libs (except big chunks which are mmap'ed and hence above the shared libs) and can run out of space easily. But really, fix malloc, not ld, if you have a problem with malloc. Not to speak of the fact that this new layout will limit mmap() space as long as you don't manually place the new space. I think I'm going back to FreeBSD... Martin
