Linux Process Memory – Shared Library Mappings in /proc/pid/maps

linuxmemoryprocessshared libraryvirtual-memory

Why does /proc/pid/maps contain a few records for the same library ? Here is an example:

7fae7db9f000-7fae7dc8f000 r-xp 00000000 08:05 536861                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20
7fae7dc8f000-7fae7de8f000 ---p 000f0000 08:05 536861                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20
7fae7de8f000-7fae7de97000 r--p 000f0000 08:05 536861                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20
7fae7de97000-7fae7de99000 rw-p 000f8000 08:05 536861                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20

What does this mean ?

Best Answer

The four records have different permissions, so they can't be merged.

  • The r-xp entry describes a block of executable memory (x permission flag). That's the code.
  • The r--p entry describes a block of memory that is only readable (r permission flag). That's static data (constants).
  • The rw-p entry describes a block of memory that is writable (w permission flag). This is for global variables of the library.
  • The ---p entry describes a chunk of address space that doesn't have any permissions (or any memory mapped to it).

All are private (p flag), meaning that if a process modifies a page (which is only possible for the writable part), that page will be copied (copy-on-write), and other processes will not see any change.

That last entry is a gap between the code segment and the data segment that's explicitly inserted by the GNU linker under certain circumstances. The purpose of this gap is to ensure that the code (shareable between processes that use the same library) and the writable data (not shareable) are never in the same page. The size of the gap is 2MB because that's the largest page size¹ that Linux uses on your architecture (amd64). See What is the purpose of seemingly unusable memory mappings in linux? for more details.

¹ Most pages are 4kB, which is the “normal” page size. But there can be pages that use fewer MMU indirections, which is slightly faster but wastes a lot of space unless the application actually uses very large blocks of memory. Linux calls these huge pages.

Source and more information for the unmapped gap: Why does gnome-panel use 290MB? by RJK. See also the entry for /proc/PID/maps in the Linux kernel documentation, Understanding Linux /proc/id/maps and /proc/$pid/maps shows pages with no rwx permissions on x86_64 linux on Stack Overflow.

Related Question