I have RH3.0 installed in an AMD64 machine.
In this system, when I look at the virtual address space mappings of a
process (say a sleep process), I see quite a few strange memory region
mappings which are neither readable, nor writable/executable and all of
them are Private (i.e. unshared). Check this:
1024 ---p /lib64/tls/libc-2.3.2.so
1024 ---p /lib64/tls/libm-2.3.2.so
1024 ---p /lib64/tls/librtkaio-2.3.2.so
1024 ---p /lib64/tls/libpthread-0.60.so
On the other hand, when I look at the same info in a Rh7.2 system, I
don't see anything like that...
Question: How do I make sense of an unreadable/unwritable/unexecutable
privately mapped memory region? What is its usage? It looks like a 100%
wastage of the process's address space. How is the process using it? Any
idea...anybody?
You can find the sample "sleep" commands below.
Thanks,
Arijit
RH3.0 on AMD64:
=============
vgamd126:arijit>sleep 400 &
[1] 19916
vgamd126:arijit>pmap 19916
Size (KB) Perm Associated files (if any)
========== ==== =============================================
16 r-xp /bin/sleep
4 rw-p /bin/sleep
132 rwxp
1108 r-xp /lib64/ld-2.3.2.so
4 rw-p /lib64/ld-2.3.2.so
4 rw-p
540 r-xp /lib64/tls/libm-2.3.2.so
1024 ---p /lib64/tls/libm-2.3.2.so
4 rw-p /lib64/tls/libm-2.3.2.so
4 rw-p
36 r-xp /lib64/tls/librtkaio-2.3.2.so
1024 ---p /lib64/tls/librtkaio-2.3.2.so
4 rw-p /lib64/tls/librtkaio-2.3.2.so
64 rw-p
1260 r-xp /lib64/tls/libc-2.3.2.so
1024 ---p /lib64/tls/libc-2.3.2.so
20 rw-p /lib64/tls/libc-2.3.2.so
16 rw-p
60 r-xp /lib64/tls/libpthread-0.60.so
1024 ---p /lib64/tls/libpthread-0.60.so
4 rw-p /lib64/tls/libpthread-0.60.so
20 rw-p
31396 r--p /usr/lib/locale/locale-archive
24 rw-p
Total Virtual Memory = 38816 KB
vgamd126:arijit>
RH7.2 in i686
==========
eurika120:arijit>sleep 400 &
[1] 11065
eurika120:arijit>pmap 11065
Size (KB) Perm Associated files (if any)
========== ==== =============================================
12 r-xp /bin/sleep
4 rw-p /bin/sleep
8 rwxp
88 r-xp /lib/ld-2.2.4.so
4 rw-p /lib/ld-2.2.4.so
4 r--p /usr/lib/locale/en_US/LC_IDENTIFICATION
4 r--p /usr/lib/locale/en_US/LC_MEASUREMENT
4 r--p /usr/lib/locale/en_US/LC_TELEPHONE
4 r--p /usr/lib/locale/en_US/LC_ADDRESS
4 r--p /usr/lib/locale/en_US/LC_NAME
4 r--p /usr/lib/locale/en_US/LC_PAPER
4 r--p /usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES
4 r--p /usr/lib/locale/en_US/LC_MONETARY
24 r--p /usr/lib/locale/en_US/LC_COLLATE
4 r--p /usr/lib/locale/en_US/LC_TIME
4 r--p /usr/lib/locale/en_US/LC_NUMERIC
4 rw-p
136 r-xp /lib/i686/libm-2.2.4.so
4 rw-p /lib/i686/libm-2.2.4.so
28 r-xp /lib/librt-2.2.4.so
4 rw-p /lib/librt-2.2.4.so
40 rw-p
1224 r-xp /lib/i686/libc-2.2.4.so
20 rw-p /lib/i686/libc-2.2.4.so
16 rw-p
52 r-xp /lib/i686/libpthread-0.9.so
32 rw-p /lib/i686/libpthread-0.9.so
172 r--p /usr/lib/locale/en_US/LC_CTYPE
24 rwxp
Total Virtual Memory = 1936 KB
eurika120:arijit>
On Fri, Sep 30, 2005 at 06:28:58PM +0530, Arijit Das wrote:
> I have RH3.0 installed in an AMD64 machine.
>
> In this system, when I look at the virtual address space mappings of a
> process (say a sleep process), I see quite a few strange memory region
> mappings which are neither readable, nor writable/executable and all of
> them are Private (i.e. unshared). Check this:
>
> 1024 ---p /lib64/tls/libc-2.3.2.so
> 1024 ---p /lib64/tls/libm-2.3.2.so
> 1024 ---p /lib64/tls/librtkaio-2.3.2.so
> 1024 ---p /lib64/tls/libpthread-0.60.so
Those are PROT_NONE mapping. As x86-64 has far bigger ELF page size
than the actual hardware page size commonly used ATM, there is usually
a gap between read-only/execute and read-write ELF segments.
It is undesirable to map anything in there (e.g. exception handling
would be very upset if you mapped a really small shared library in the
hole inside of another shared library) and PROT_NONE mapping prevents that.
If you strace some small process, you'll see that creating them is at most
as expensive as would be unmapping the regions.
Jakub