Strange Virtual Memory Mapping...!

Strange Virtual Memory Mapping...!

[Arijit Das]

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>

Re: Strange Virtual Memory Mapping...!

[Jakub Jelinek]

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